Cabeceras de seguridad HTTP: qué hace cada una y cómo activarlas en tu servidor (generador gratis)

Hay una trampa de falsa seguridad muy común: “mi sitio tiene el candado verde (HTTPS), así que está seguro”. El HTTPS cifra el camino — nadie lee la contraseña en tránsito. Pero no le dice al navegador cómo comportarse dentro de la página. Y, por defecto, el navegador hace varias cosas peligrosas: deja que tu sitio sea puesto en un <iframe> de un estafador, “adivina” tipos de archivo, ejecuta scripts de cualquier origen. Las cabeceras de seguridad HTTP son media docena de líneas en la config del servidor que cierran esas puertas.

¿Qué cabeceras de seguridad HTTP realmente importan?

• Strict-Transport-Security (HSTS) — obliga al navegador a hablar solo por HTTPS, aunque alguien intente forzar HTTP. Actívala solo cuando el HTTPS esté 100% en línea.
• X-Content-Type-Options: nosniff — impide que el navegador “adivine” que un archivo es otra cosa (un .txt volviéndose script). Cierra toda una clase de ataques.
• X-Frame-Options: SAMEORIGIN — prohíbe que tu sitio sea embebido en un iframe de terceros. Es el anti-clickjacking (ese truco del botón invisible sobre el tuyo).
• Referrer-Policy — controla cuánto de la URL actual se filtra en la cabecera Referer cuando el usuario hace clic hacia afuera. Evita filtrar rutas internas y tokens en la URL.
• Permissions-Policy — apaga APIs del navegador que tu sitio no usa (cámara, micrófono, geolocalización). Si entra un script malicioso, no puede pedir tu webcam.
• Content-Security-Policy (CSP) — la más poderosa contra XSS: dice exactamente de dónde pueden venir scripts, imágenes y estilos. Todo lo que no está en la lista, el navegador lo rechaza. También es la más trabajosa de ajustar — de ahí el consejo de oro de abajo.

¿Cuál es la regla de oro para implementar el CSP?

Trabar el CSP de una vez rompe sitios (desaparecen imágenes, desaparecen scripts legítimos). La forma correcta: subilo primero como Content-Security-Policy-Report-Only. En ese modo solo reporta lo que se bloquearía, sin bloquear nada. Mirás la consola/el reporte, ajustás la política hasta que deje de quejarse de lo legítimo, y recién entonces cambiás al Content-Security-Policy de verdad.

¿Dónde configurar las cabeceras de seguridad HTTP?

Depende de tu servidor — y el generador de abajo escupe los dos, listos para pegar:

• Apache (la mayoría del hosting compartido, incluido el de Hostinger): va en el .htaccess, dentro de <IfModule mod_headers.c>.
• Nginx: va en el bloque server { ... } con add_header ... always;.

Después de aplicar, probalo: poné tu dominio en securityheaders.com o en el Mozilla Observatory — dan una nota y listan lo que falta. La nota sube al instante.

Marcá las cabeceras que querés en el generador de abajo y llevate la configuración lista para pegar. 👇

Preguntas frecuentes

¿No basta con HTTPS? No. El HTTPS cifra el camino pero no le dice al navegador cómo actuar dentro de la página — clickjacking, XSS y fuga de Referer pasan con el candado puesto. Las cabeceras son la segunda capa.
¿El CSP va a romper mi sitio? Puede, si trabás todo de una vez. Empezá en Content-Security-Policy-Report-Only (solo reporta, no bloquea), ajustá, y recién entonces cambiá al CSP real.
¿Cómo lo pruebo? Pasá tu dominio por securityheaders.com o el Mozilla Observatory — dan una nota y listan lo que falta.

Esta guía es parte de la serie Seguridad de sitios. Referencias: MDN — CSP, securityheaders.com, OWASP Secure Headers.