Checklist de seguridad web: CSP, HSTS, cabeceras

Este checklist de seguridad web reúne los controles que protegen una web de marketing típica: HTTPS con HSTS, una Content Security Policy, un conjunto corto de cabeceras de respuesta, formularios y cookies seguros, acceso de administración protegido y dependencias actualizadas. Nada exótico. Casi todo es configuración que se hace una vez y se comprueba después de cada publicación.

Las webs de marketing rara vez guardan datos de pago, así que muchos equipos las consideran de bajo riesgo. Aun así, recogen contactos, ejecutan scripts de terceros y llevan tu marca. Una página de inicio alterada o un formulario interceptado son incidentes reales.

¿Por qué una web de marketing necesita un checklist de seguridad?

Casi nadie ataca a mano la web de una empresa pequeña. Los atacantes rastrean millones de sitios de forma automática en busca de fallos conocidos y aprovechan lo que encuentran. Basta un plugin desactualizado, un panel de administración expuesto o una cabecera que falta.

Las consecuencias habituales son poco vistosas, pero caras:

• Scripts inyectados que redirigen a los visitantes, minan criptomonedas o roban datos de formularios.
• Páginas de spam añadidas a tu dominio, que pueden dañar tu posicionamiento.
• Fugas de contactos desde formularios que guardan los datos de forma insegura o los envían a donde no deben.
• Robo de cuentas del CMS por contraseñas reutilizadas.

Un checklist corto y aplicado de verdad elimina la mayor parte de ese riesgo. Además, te da respuestas claras cuando el equipo de seguridad de un cliente te envía un cuestionario.

Transporte: HTTPS en todo y después HSTS

Cada página, recurso y llamada a la API debe cargarse por HTTPS. Redirige HTTP a HTTPS con una redirección permanente y corrige cualquier aviso de contenido mixto.

Después, añade HTTP Strict Transport Security. HSTS indica al navegador que use solo HTTPS en tu dominio durante un tiempo determinado, aunque alguien escriba http:// o siga un enlace antiguo.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Actívalo por pasos. Empieza con un max-age corto, por ejemplo un día, y comprueba que ningún subdominio falla. Luego súbelo a uno o dos años. Añade preload y envía el dominio a la lista de precarga de los navegadores solo cuando estés seguro de que todos los subdominios admiten HTTPS. Salir de esa lista lleva mucho tiempo.

Una Content Security Policy que funcione de verdad

Una Content Security Policy (CSP) le dice al navegador desde qué orígenes puede ejecutar scripts, cargar estilos, incrustar marcos y enviar datos. Es la defensa más fuerte contra el cross-site scripting, porque el código inyectado se bloquea aunque llegue a la página.

El enfoque moderno es una política estricta basada en nonce, no una larga lista de dominios permitidos:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{random}' 'strict-dynamic';
  style-src 'self' 'nonce-{random}';
  img-src 'self' data: https:;
  connect-src 'self';
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  object-src 'none';
  upgrade-insecure-requests

El servidor genera un nonce aleatorio nuevo en cada respuesta y lo añade a cada etiqueta script de confianza. 'strict-dynamic' permite que esos scripts carguen sus propias dependencias. Lo que se inyecte sin el nonce no se ejecuta.

Cómo introducir la CSP sin romper la web:

1. Empieza en modo informe. Envía Content-Security-Policy-Report-Only y recoge los informes de infracciones durante una o dos semanas.
2. Haz inventario de terceros. Analítica, chats, gestores de etiquetas, vídeo incrustado. Cada uno requiere una decisión consciente.
3. Ajusta y después aplica. Corrige o elimina lo que señalen los informes y pasa a la cabecera que bloquea.
4. Vigila tras cada publicación. Las funciones nuevas suelen añadir orígenes nuevos.

Un gestor de etiquetas que permite a marketing añadir cualquier script va en contra de la CSP. Acuerda de antemano quién puede añadir código de terceros y cómo se revisa.

La guía de MDN sobre Content Security Policy explica cada directiva en detalle.

El resto del checklist de seguridad web: cabeceras que importan

Además de HSTS y CSP, unas pocas cabeceras cierran huecos habituales. El OWASP Secure Headers Project mantiene una referencia actualizada.

X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Cross-Origin-Opener-Policy: same-origin
X-Frame-Options: DENY

• X-Content-Type-Options: nosniff impide que el navegador adivine el tipo de archivo y bloquea toda una clase de ataques por tipo de contenido.
• Referrer-Policy limita cuánto de tus URLs llega a otros sitios. strict-origin-when-cross-origin es un valor razonable por defecto.
• Permissions-Policy desactiva funciones del navegador que tu web no usa nunca, como la cámara o la ubicación.
• Cross-Origin-Opener-Policy aísla tus páginas de las ventanas abiertas por otros sitios.
• X-Frame-Options evita el clickjacking en navegadores antiguos. En los modernos, la directiva CSP frame-ancestors hace lo mismo. Envía las dos.

Olvídate de X-XSS-Protection. Está obsoleta, los navegadores modernos la ignoran y en algunos antiguos causaba sus propios problemas.

Publica también un archivo /.well-known/security.txt, definido en el RFC 9116. Indica a los investigadores de seguridad cómo avisarte de un problema.

Formularios, cookies y acceso de administración

Los formularios son el lugar donde una web de marketing maneja datos personales, así que merecen el mismo cuidado que una página de inicio de sesión.

• Valida en el servidor. Las comprobaciones en el navegador ayudan al usuario, pero no te protegen.
• Limita la frecuencia de envíos. Un límite de peticiones por IP frena el spam y los abusos.
• Escapa la salida. Todo lo que envía un visitante debe tratarse como texto al mostrarse en correos, paneles o el CMS.
• Recoge menos. Cada campo que no necesitas son datos que no tienes que proteger.
• Configura las cookies. Las cookies de sesión necesitan Secure, HttpOnly y un valor de SameSite.

Para las cuentas del CMS y del alojamiento:

• Activa la autenticación multifactor para cada usuario.
• Da a cada persona su propia cuenta con el rol mínimo que necesite.
• Retira el acceso el mismo día en que alguien deja el proyecto.
• Si la plataforma lo permite, saca los paneles de administración de URLs públicas previsibles.

Dependencias, alojamiento y secretos

La mayoría de los ataques usan vulnerabilidades conocidas que ya tienen solución. Actualizar es el punto menos emocionante de esta lista y uno de los más importantes.

• Sube el lockfile al repositorio. Las compilaciones deben instalar exactamente las versiones que probaste.
• Automatiza los avisos de actualización. Herramientas como Dependabot o Renovate señalan paquetes vulnerables. Alguien tiene que encargarse de revisarlos.
• Actualiza el framework a tiempo. En marzo de 2025, Next.js publicó CVE-2025-29927, un fallo que permitía saltarse las comprobaciones de autorización hechas en el middleware. Las versiones corregidas salieron rápido. El riesgo quedó en las webs que no actualizaron.
• Mantén los secretos fuera del repositorio. Las claves de API van en las variables de entorno del alojamiento, nunca en el código ni en el bundle del cliente.
• Haz copias de seguridad y prueba a restaurarlas. Una copia que nunca has restaurado es una esperanza, no una copia de seguridad.

La plataforma que elijas cambia cuánto de esto recae en ti. Un CMS lleno de plugins implica más código de terceros que actualizar. Una arquitectura estática o renderizada en servidor tiene menos piezas móviles, pero igualmente necesita actualizar dependencias. Conviene sopesarlo antes de elegir.

Si de todos modos vas a cambiar de plataforma, incluye estas comprobaciones en el plan desde el principio. En nuestra guía de migración web sin perder SEO verás dónde encajan alrededor del lanzamiento.

Cómo probar tu configuración

1. Analiza la web con MDN HTTP Observatory para revisar cabeceras y configuración TLS.
2. Abre la consola del navegador en las páginas clave y busca infracciones de CSP y contenido mixto.
3. Ejecuta el comando de auditoría de tu gestor de paquetes y revisa los resultados.
4. Prueba los formularios con datos inesperados: cadenas largas, HTML, envíos rápidos repetidos.
5. Repite tras cada publicación importante. La configuración de seguridad se degrada cuando nadie la revisa.

Siguiente paso: seguridad desde el primer commit

Cada proyecto de Kyvrel, también el desarrollo de aplicaciones web, incluye por defecto HTTPS, HSTS, una CSP basada en nonce, las cabeceras anteriores, formularios con límite de envíos y un archivo security.txt. Una aplicación web empieza en 25.000 $ por un MVP de 15 pantallas, con un plazo habitual de 12-16 semanas. Nuestro plan de mantenimiento de 3 meses, por 1500 $, cubre las actualizaciones de dependencias y los parches de seguridad tras el lanzamiento.

¿Todavía eliges plataforma? Nuestra comparativa entre WordPress y Next.js explica qué supone cada opción en actualizaciones y mantenimiento a largo plazo.