Guías

Cómo corregir cabeceras de seguridad (CSP, HSTS)

La ausencia de cabeceras de seguridad expone las aplicaciones web a vulnerabilidades como cross-site scripting (XSS), clickjacking, degradación de protocolo y filtración de datos de sesión.

Respuesta breve

Implemente Strict-Transport-Security con un año de duración y preload, defina una Content-Security-Policy restrictiva, configure X-Content-Type-Options: nosniff y frame-ancestors 'none'.

Diagnosticar cabeceras de respuesta ausentes

Antes de modificar la configuración del servidor web, inspeccione las cabeceras actuales mediante curl -IL o un analizador automatizado. Identifique en qué capa se gestiona TLS y se inyectan las respuestas: en el servidor de origen (Nginx, Apache), proxy inverso o red de distribución CDN. Verifique que ningún proxy intermedio esté eliminando las cabeceras.

Configuración segura de Strict-Transport-Security (HSTS)

HSTS obliga a los navegadores a conectarse exclusivamente a través de HTTPS, neutralizando ataques de degradación de cifrado. Inicie las pruebas con max-age=86400 (un día). Tras comprobar que todos los subdominios y recursos admiten HTTPS sin errores, aplique la directiva definitiva: max-age=31536000; includeSubDomains; preload. Nunca establezca max-age=0 en entornos de producción.

Construir una política Content Security Policy (CSP) sólida

CSP delimita con precisión qué orígenes y recursos pueden ejecutarse en el navegador. Comience utilizando la cabecera Content-Security-Policy-Report-Only con report-to para recopilar eventos sin interrumpir el funcionamiento de los usuarios. Defina default-src 'self', script-src 'self' con valores nonce o hashes en lugar de 'unsafe-inline', restrinja object-src 'none' y declare frame-ancestors 'none'.

Prevenir clickjacking, sniffing MIME y fugas de referrer

Evite que su sitio sea incrustado en iframes maliciosos mediante frame-ancestors 'none' en CSP y X-Frame-Options: DENY de respaldo para clientes antiguos. Bloquee la interpretación incorrecta de tipos MIME con X-Content-Type-Options: nosniff y controle la información transmitida en enlaces externos con Referrer-Policy: strict-origin-when-cross-origin.

Despliegue en el servidor web y comprobación

En Nginx, declare las cabeceras dentro del bloque server HTTPS con add_header y el parámetro always (por ejemplo: add_header X-Content-Type-Options "nosniff" always;), asegurando su inclusión en respuestas de error 4xx y 5xx. En Apache, utilice mod_headers con Header always set. Valide la sintaxis con nginx -t y reinicie el servicio antes de volver a escanear.

Cabeceras de seguridad: HTTPS, CSP, protección de marcos, MIME, referente y aislamiento del navegador.

Iniciar auditoría gratis →

Preguntas

Preguntas frecuentes

¿Es seguro habilitar HSTS preload de inmediato en producción?

No. Pruebe primero Strict-Transport-Security con max-age=86400 (un día) y compruebe que todos los subdominios funcionan con HTTPS antes de registrar el dominio en hstspreload.org con max-age=31536000.

¿Cómo desplegar Content Security Policy sin romper scripts externos o analítica?

Implemente primero Content-Security-Policy-Report-Only para monitorizar infracciones, liste los endpoints necesarios y utilice nonces o hashes antes de activar la política definitiva.