Checklist de seguridad para una web corporativa: lo mínimo que debe cumplir

Una web corporativa segura cumple, como mínimo, siete condiciones: sirve todo por HTTPS con certificado válido y redirección forzada; envía cabeceras HTTP que limitan qué puede cargar y hacer el navegador (CSP, HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy); valida los formularios en el servidor y los protege contra el spam; tiene copias de seguridad probadas; mantiene actualizado todo el software; recoge solo los datos personales imprescindibles; y publica un archivo security.txt para que quien detecte un fallo sepa a quién avisar. Todo se puede comprobar desde el navegador y la terminal en menos de una hora.

La mayoría de los ataques a webs de empresa no son dirigidos. Son programas que recorren internet buscando un plugin sin actualizar, un formulario sin protección o un panel con contraseña débil. Esta lista es la que reviso en cada web que entrego o audito, sea WordPress o a medida.

1. HTTPS en todo el sitio

HTTPS cifra la conexión entre el visitante y el servidor. Sin él, cualquiera en la misma red puede leer lo que se envía en un formulario y modificar lo que se muestra. Los navegadores marcan como «no seguro» cualquier sitio HTTP.

Lo mínimo:

• Certificado válido y renovado automáticamente. Let's Encrypt lo da gratis y la mayoría de alojamientos lo integran.
• Redirección 301 de todas las URL HTTP a HTTPS, también la versión con y sin www.
• Ningún recurso cargado por HTTP dentro de una página HTTPS (contenido mixto). Una imagen o un script en HTTP rompe el candado y el navegador puede bloquearlo.

2. Cabeceras HTTP de seguridad

Son instrucciones que el servidor envía al navegador con cada respuesta y que limitan lo que la página puede hacer. Cuestan unas líneas de configuración y cierran familias enteras de ataques. Las cinco que importan:

Sobre la CSP, dos avisos. Primero: una política estricta puede romper cosas (el chat de terceros, la analítica, las fuentes externas). Empieza en modo informe con Content-Security-Policy-Report-Only, mira qué bloquearía y ajusta antes de activarla. Segundo: evita 'unsafe-inline' en script-src si puedes; con eso la política pierde casi todo su valor contra XSS. Si tu web usa un gestor de contenidos con scripts en línea, un nonce o un hash por script es la alternativa.

Sobre HSTS: una vez recibida, el navegador no volverá a cargar el sitio por HTTP durante el tiempo indicado. Si el certificado falla, la web queda inaccesible hasta arreglarlo.

3. Formularios: validar en servidor, frenar el spam

El formulario de contacto es la parte de la web que acepta datos de desconocidos. Dos reglas:

• Validar siempre en el servidor. La validación en el navegador es comodidad para el usuario, no seguridad: cualquiera la salta enviando la petición directamente. El servidor debe comprobar tipo, longitud y formato de cada campo, rechazar lo que no espera y escapar todo lo que vaya a mostrarse o a guardarse. Las guías de OWASP sobre validación de entrada son la referencia.
• Proteger contra el envío automatizado. Tres capas que se combinan: un campo oculto (honeypot) que los humanos no ven y los robots rellenan; un límite de envíos por dirección IP y por minuto; y, si el spam sigue, un desafío ligero (Turnstile, reCAPTCHA) como último recurso, porque añade fricción y, en el caso de servicios externos, envía datos del visitante a un tercero que hay que recoger en la política de privacidad.

Si el formulario adjunta archivos, limita tipos y tamaño y nunca los sirvas desde la misma ruta donde se suben.

4. Copias de seguridad que se han probado

Una copia de seguridad que nunca se ha restaurado es una hipótesis. Lo mínimo:

• Copia automática diaria de archivos y base de datos, con retención de al menos 30 días.
• Al menos una copia fuera del servidor de producción (otro proveedor o almacenamiento independiente). Si el servidor cae o lo cifran, la copia que estaba en él cae también.
• Una restauración de prueba cada trimestre, en un entorno aparte, cronometrada. El tiempo que tarda es tu tiempo real de recuperación.
• Copia manual antes de cada actualización importante.

5. Actualizaciones y superficie de ataque

La mayoría de las intrusiones en webs de empresa explotan vulnerabilidades ya conocidas y ya corregidas en software que nadie actualizó. En WordPress, el grueso está en plugins y temas, no en el núcleo. En una web a medida, en las bibliotecas y en el sistema del servidor.

• Actualiza el núcleo, los plugins, el tema y las dependencias al menos una vez al mes, con copia previa y comprobación posterior.
• Elimina lo que no uses: plugins desactivados, temas antiguos, cuentas de usuarios que ya no están, archivos de instalación. Lo que no existe no se puede atacar.
• Protege el panel de administración: contraseñas largas y únicas, segundo factor de autenticación, límite de intentos de acceso y, si es posible, acceso restringido por IP o por VPN.
• Revisa quién tiene acceso al alojamiento, al dominio y al panel, y con qué permisos.

6. Mínimos datos personales

La seguridad y la protección de datos se cruzan aquí. El RGPD exige recoger solo los datos necesarios para la finalidad (artículo 5) y protegerlos con medidas técnicas adecuadas (artículo 32). Para una web corporativa eso se traduce en:

• Formularios que piden lo imprescindible. Si para responder a una consulta basta nombre y correo, no pidas teléfono, empresa y cargo como obligatorios.
• Información clara en el momento de la recogida: quién trata los datos, para qué, cuánto tiempo y cómo ejercer los derechos. Enlazada desde el propio formulario.
• Plazos de conservación definidos y aplicados: los mensajes de contacto de hace cuatro años no deberían seguir en la base de datos de la web.
• Cookies y scripts de terceros solo con consentimiento previo cuando no sean técnicamente necesarios, siguiendo la guía de cookies de la AEPD.
• Un procedimiento para avisar a la AEPD en 72 horas si hay una brecha que afecte a datos personales (artículo 33). Saber a quién llamar antes de necesitarlo.

7. security.txt

Si alguien descubre un fallo de seguridad en tu web, ¿cómo te avisa? El estándar security.txt (RFC 9116) resuelve esto con un archivo de texto en /.well-known/security.txt que indica un contacto, una fecha de caducidad y, opcionalmente, un idioma preferido y una política de divulgación. Ejemplo mínimo:

Contact: mailto:[email protected]
Expires: 2027-10-29T00:00:00.000Z
Preferred-Languages: es, en

El campo Expires es obligatorio y conviene que no supere un año. Pon una fecha en el calendario para renovarlo.

Tabla de comprobación

Imprímela o cópiala a una hoja compartida. Revísala al entregar la web y después cada tres meses.

La seguridad de una web corporativa no se compra una vez. Se revisa cada trimestre.

Si quieres que revise la tuya con esta lista, el servicio de desarrollo web incluye una auditoría técnica inicial y el mantenimiento recurrente cubre las comprobaciones mensuales y trimestrales. También puedes escribirme con el resultado de tu propia revisión.