Guía
Cabeceras de seguridad HTTP: qué enviar y cómo comprobarlas
4 minutos de lectura · Publicado
Qué cabeceras de seguridad debe enviar tu sitio
Un sitio moderno suele necesitar varias cabeceras trabajando juntas: Content-Security-Policy para limitar qué scripts y recursos puede cargar el navegador, Strict-Transport-Security para forzar HTTPS en visitas futuras, y X-Content-Type-Options para evitar que el navegador adivine tipos de archivo de forma insegura. Cada una cubre un riesgo distinto, y la ausencia de una sola no siempre se nota hasta que algo falla en producción.
A esto se suman Referrer-Policy, que controla cuánta información de la URL de origen se envía a otros sitios, y Permissions-Policy, que restringe el acceso a cámara, micrófono o geolocalización desde el propio dominio o desde iframes. Ninguna de estas cabeceras sustituye a un buen código, pero reducen el impacto de errores que ya existen en el frontend o en integraciones de terceros.
Cómo comprobar las cabeceras desde fuera
La forma más directa es pedir la página con curl -I o con las herramientas de desarrollador del navegador, en la pestaña de red, y mirar la respuesta completa, no solo el cuerpo HTML. Ahí aparecen todas las cabeceras que el servidor decidió enviar, incluidas las de seguridad, las de caché y las que revelan tecnología del servidor sin necesidad.
Conviene repetir la comprobación en producción y no solo en un entorno de pruebas, porque muchas veces las cabeceras se configuran en un proxy o CDN que se añade justo antes de publicar, y ese paso no siempre se replica en staging. También vale la pena revisar redirecciones HTTP a HTTPS, porque una redirección sin HSTS deja una ventana breve donde el tráfico viaja sin cifrar.
Errores frecuentes que vemos en revisiones
Una política CSP con unsafe-inline o con comodines amplios da la sensación de estar protegido sin aportar mucho, porque permite casi cualquier script. Otro patrón habitual es un HSTS presente pero sin includeSubDomains, de modo que un subdominio olvidado sigue aceptando conexiones sin cifrar aunque el dominio principal esté bien configurado.
En cookies, faltan con frecuencia los atributos Secure, HttpOnly y SameSite, sobre todo en cookies de sesión creadas por librerías antiguas con valores por defecto permisivos. En CORS, un Access-Control-Allow-Origin con comodín combinado con credenciales habilitadas es un error que suele pasar desapercibido en revisiones rápidas de código, precisamente porque requiere mirar la configuración en vivo del servidor y no solo el código fuente.
Qué hace Audixa con la configuración web en vivo
Audixa revisa TLS, cabeceras, cookies, CORS y redirecciones tal como las recibe cualquier visitante, comparando lo observado con prácticas conocidas. No ejecuta el código fuente del proyecto ni instala sus dependencias; trabaja con lo que el servidor realmente entrega y con lo que el repositorio deja ver, y señala diferencias entre ambos cuando existen.
Además de cabeceras web, Audixa busca secretos en el código fuente, patrones de código riesgosos y avisos conocidos de dependencias, y puede anotar errores de proveedores de pago como una clave secreta expuesta en código de cliente o un webhook que no verifica firmas. Cada hallazgo se entrega con el archivo o la respuesta concreta donde aparece, para que el equipo pueda decidir qué corregir primero.
Antes de lanzar: checklist rápido
Antes de publicar conviene confirmar cinco cosas: HSTS activo con includeSubDomains, una CSP que no dependa de unsafe-inline, cookies de sesión con Secure y HttpOnly, CORS restringido a los orígenes que realmente lo necesitan, y redirecciones HTTP a HTTPS sin pasos intermedios sin cifrar. Ninguna requiere herramientas complejas, solo revisar la respuesta real del servidor.
Borrar un archivo con una clave del repositorio no la elimina del historial de Git, así que conviene revisar también ese punto antes de dar por cerrada la lista. Para profundizar, la guía de checklist de lanzamiento y la nota sobre secretos en el historial de Git amplían varios de estos puntos con ejemplos concretos.
Sigue por aquí
Que las comprobaciones repetibles se ejecuten por ti
Un proyecto y un análisis al mes son gratis. Ves cuántos hallazgos hay y qué tan graves son; los títulos y la evidencia se desbloquean en un plan de pago.