Formato nuevo
Headers HTTP de seguridad: qué configurar en un sitio
Los headers HTTP son campos de servicio en la respuesta del servidor: dicen al navegador cómo tratar la página (tipo de contenido, cache, redirect, reglas de seguridad). Algunos cortan de forma directa riesgos de XSS, clickjacking y fugas de datos.
Abajo: un set práctico de headers de seguridad. El panorama general request/response está en el artículo del protocolo HTTP; aquí el foco es protección. Antes de editar — backup del config y prueba en staging.
Qué son los headers HTTP
Al abrir una URL, el navegador recibe no solo HTML sino metadata de respuesta: `Content-Type`, `Location`, `Cache-Control`, flags de cookies, directivas de seguridad. Sin ellos el protocolo no sabe cómo mostrar la página con seguridad.
Los headers de seguridad no sustituyen updates del CMS ni contraseñas. Son una capa de protección del navegador encima de la higiene normal del servidor.
Antes de configurar:
- backup de nginx/Apache/`.htaccess`
- probar en una copia del sitio
- listar dominios, CDN, analytics, widgets
HSTS: solo HTTPS
`Strict-Transport-Security` dice al navegador: para este host, usa solo HTTPS durante un tiempo fijado. Corta el riesgo de volver a HTTP abierto y parte de los ataques de downgrade.
Actívalo cuando el certificado y los redirects estén estables. `includeSubDomains` y `preload` — a propósito: un preload malo cuesta deshacer.
Clickjacking y MIME: X-Frame-Options, X-Content-Type-Options
`X-Frame-Options` (y CSP `frame-ancestors`) limita embeber el sitio en iframes de otras páginas — protección contra clickjacking. Valores típicos: `DENY` o `SAMEORIGIN`.
`X-Content-Type-Options: nosniff` evita que el navegador adivine el tipo de archivo más allá del `Content-Type` declarado — menos sorpresas con ejecución de scripts.
CSP: política de contenido
`Content-Security-Policy` fija desde dónde pueden cargarse scripts, estilos, imágenes y frames. Es la herramienta moderna principal contra muchos casos XSS cuando está bien puesta.
Empieza inventariando dominios (tu host, CDN, analytics, chat). Report-Only ayuda a ver violaciones sin roturas. Un `default-src 'none'` de golpe sin prep casi siempre rompe widgets.
Referrer-Policy y Permissions-Policy
`Referrer-Policy` limita cuánta URL va en `Referer` en las navegaciones — menos fuga de path y query. Un equilibrio habitual: `strict-origin-when-cross-origin`.
`Permissions-Policy` (antes Feature-Policy) desactiva o limita APIs potentes del navegador (cámara, mic, geolocalización) cuando el sitio no las necesita.
Set mínimo para empezar:
- HSTS (tras HTTPS)
- X-Content-Type-Options: nosniff
- frame-ancestors / X-Frame-Options
- Referrer-Policy
- un borrador de CSP en Report-Only
Cómo desplegar y verificar
Fija headers en nginx/`add_header`, Apache/`Header set` o el panel del hosting. PHP en la plantilla es un fallback — peor para estáticos y cache.
Tras el deploy revisa home, páginas de login, formularios y páginas con widgets. Mira la consola por errores CSP. Documenta la política para el equipo: un script nuevo de analytics no debería romper prod por sorpresa.
FAQ
¿Dónde se ven los headers?
DevTools → Network → response del documento, `curl -I https://sitio/`, scanners online de security headers. Revisa el host HTTPS en vivo.
¿Dónde se configuran?
En el config del servidor web (nginx, Apache/`.htaccess`), a veces en la app (PHP `header()`, middleware). Mejor servidor/CDN — una vez para todo el sitio.
¿Sigue haciendo falta X-XSS-Protection?
En navegadores modernos está desfasado y puede molestar. Apóyate en CSP, no en el filtro XSS viejo. No lo trates como base de la protección.
¿CSP romperá el sitio?
Un CSP estricto que ignore scripts — sí. Empieza con Report-Only o una política suave, mira reports y luego aprieta.
¿Se puede usar HSTS sin HTTPS?
No. Primero HTTPS estable y redirect http→https; luego HSTS.
¿Esto afecta al SEO?
De forma indirecta: seguridad y confianza, menos riesgo de hacks/spam. No hay un «header para primera página». Los rankings siguen al trabajo en el sitio; meses planificados tras arrancar el SEO.
¿Feature-Policy o Permissions-Policy?
El nombre actual es Permissions-Policy (limita cámara, geolocalización, etc.). Feature-Policy viejo aún aparece en guías.
¿Headers de seguridad aún en cero?
Montamos HSTS, CSP en Report-Only y el mínimo anti-clickjacking — sin romper widgets en prod.
Hablar del proyecto
