Cabeceras de seguridad: lo que la respuesta de tu servidor le indica al navegador
Mira lo que tu servidor le indica al navegador: CSP, HSTS, CORS y las demás cabeceras de seguridad, cada una evaluada por el valor que envía. Resultado en pantalla y PDF completo.
Qué indica una cabecera de seguridad, y cómo el análisis lee la política
Toda respuesta HTTP trae, antes del contenido, un conjunto de cabeceras. Una parte describe el contenido: tipo, tamaño, reglas de caché. Otra parte indica al navegador qué puede hacer con la página: desde qué orígenes cargar scripts y otros recursos, si la página puede mostrarse dentro de un iframe, si las próximas visitas deben usar HTTPS obligatoriamente y cuánto de la dirección enviar a otros sitios como referencia.
Estas instrucciones las ejecuta el navegador del usuario, no el servidor. Por eso limitan el efecto de las fallas de la aplicación: un script inyectado en una página con una Content-Security-Policy restrictiva no se carga, aunque la inyección exista. La cabecera no corrige la falla. Impide que la falla se convierta en ejecución.
Cómo lee el análisis. Solicita la página principal por HTTP y por HTTPS, registra cada redirección hasta la respuesta final y lee las cabeceras de esa respuesta y de las intermedias. Para cada política, evalúa las directivas. Una Content-Security-Policy con unsafe-inline en script-src se registra como presente pero ineficaz. Un Strict-Transport-Security que solo aparece en la última respuesta de la cadena se registra como tardío, porque la primera solicitud ya ocurrió sin protección. Para CORS, envía solicitudes con distintos valores de Origin y observa lo que devuelve Access-Control-Allow-Origin.
El análisis usa el mismo motor de cidguard. Cada hallazgo trae severidad, el valor leído en la respuesta y las instrucciones de corrección. Los términos del resultado están explicados en el glosario.
Cada cabecera, y qué se evalúa en ella
default-src, script-src, object-src, base-uri y frame-ancestors. Los comodines y las palabras clave unsafe-inline y unsafe-eval en script-src se registran como debilitamiento de la política.max-age (mínimo de un año), includeSubDomains y en qué respuesta de la cadena de redirecciones aparece la cabecera.nosniff, que impide al navegador reinterpretar el tipo de contenido declarado por el servidor.Access-Control-Allow-Origin y Access-Control-Allow-Credentials devueltos a solicitudes con orígenes de prueba.De la primera solicitud al informe
- 01
Indica el dominio
Solo el dominio. Sin cuenta, sin tarjeta y sin instalar nada.
- 02
El análisis recorre la cadena
Solicita la página principal por HTTP y por HTTPS, sigue cada redirección y lee las cabeceras de todas las respuestas.
- 03
La nota aparece en pantalla
Nota de 0 a 100, calculada con la fórmula del producto, con los hallazgos más graves visibles.
- 04
El informe llega por correo
PDF completo con el valor leído en cada cabecera y las instrucciones de corrección, enviado a un correo del dominio analizado.
La cabecera solo aparece en la última respuesta. La primera visita al dominio raíz ocurre sin protección, y se registra como HSTS tardío.
Por qué solo a un correo del dominio analizado. El informe describe debilidades de un dominio específico. Enviarlo a cualquier dirección permitiría que terceros obtuvieran ese análisis sin relación con el dominio. Si no tienes correo en el dominio, contáctanos y enviamos el informe después de confirmar tu relación con él.
Qué hace el análisis en el objetivo
Solicitar la página principal
Una solicitud por HTTP y una por HTTPS a la página principal, como las de un navegador, para leer las cabeceras devueltas.
Seguir la cadena de redirecciones
Se registra cada salto entre http y https y entre hosts, con las cabeceras de cada respuesta intermedia.
Enviar solicitudes con origen de prueba
Pocas solicitudes con distintos valores en la cabecera Origin, para observar lo que devuelve el servidor en Access-Control-Allow-Origin.
Evaluar la política, no la presencia
Cada cabecera se lee por su valor: directivas, tiempo de vida, cobertura de subdominios y orden en la cadena.
Sondear puertos y servicios
El escaneo de puertos alcanza infraestructura que puede pertenecer al proveedor, como en PaaS y CDN. Este tipo de prueba requiere autorización formal del responsable del entorno.
Enumerar rutas
No hay intentos de descubrir rutas como /admin o /.env con listas de palabras. Ese procedimiento genera volumen de solicitudes en el objetivo y solo se ejecuta con autorización.
Buscar fallas en la aplicación
XSS, paneles expuestos, claves en archivos JavaScript y source maps requieren solicitudes más allá de la página principal. Estos vectores forman parte del análisis completo de la plataforma, con autorización.
Cubrir todo el inventario
El resultado cubre el dominio indicado. Subdominios, entornos de pruebas y servicios auxiliares forman parte del análisis completo de la plataforma.
Preguntas frecuentes
¿Qué son las cabeceras de seguridad HTTP?
Son cabeceras de respuesta que indican al navegador qué puede hacer la página: desde qué orígenes cargar scripts y otros recursos (Content-Security-Policy), si debe usar HTTPS en las próximas visitas (Strict-Transport-Security), si puede mostrarse en un iframe (X-Frame-Options y frame-ancestors), si puede reinterpretar el tipo de contenido (X-Content-Type-Options), cuánto de la URL enviar como referencia (Referrer-Policy) y qué APIs del navegador usar (Permissions-Policy). Se configuran en el servidor o en el CDN y las ejecuta el navegador del usuario.
¿Qué cabecera tiene más efecto?
Strict-Transport-Security y Content-Security-Policy. La primera hace que el navegador use HTTPS antes de cualquier solicitud en las visitas siguientes, lo que elimina la ventana en la que la primera solicitud por HTTP puede ser interceptada. La segunda limita desde dónde se pueden cargar y ejecutar scripts, lo que impide que una inyección de contenido se convierta en ejecución de código en el navegador.
Tengo CSP configurada. ¿Por qué el análisis señala un problema?
El análisis evalúa las directivas, no la presencia de la cabecera. Una política con unsafe-inline en script-src permite scripts incrustados en la página, el vector más común de XSS. Una política con default-src * permite cualquier origen. En ambos casos la cabecera existe, pero no restringe lo que debería. El hallazgo nombra la directiva y el valor que debilita la política.
¿El análisis detecta CORS mal configurado?
Sí. Envía solicitudes con valores de Origin que el servidor no debería aceptar y lee Access-Control-Allow-Origin y Access-Control-Allow-Credentials en la respuesta. Dos patrones se registran como falla: que el servidor refleje cualquier origen recibido, y la combinación de un origen permisivo con Allow-Credentials en true, que permite a otro sitio hacer solicitudes autenticadas en nombre del usuario.
¿Prueba la redirección de HTTP a HTTPS?
Sí. El análisis solicita el dominio por HTTP y sigue cada redirección hasta la respuesta final. Registra si la cadena termina en HTTPS, si el dominio raíz y el www se comportan igual y en qué respuesta aparece Strict-Transport-Security. Cuando la cabecera solo está en la respuesta final, la primera solicitud por HTTP ya ocurrió sin protección, y el hallazgo se registra como HSTS tardío.
¿Es lo mismo que un escáner de vulnerabilidades de la aplicación?
No. Este análisis lee la configuración de respuesta del servidor en la página principal. Encontrar XSS, paneles de administración expuestos, claves en archivos JavaScript o source maps en producción requiere solicitudes a la aplicación más allá de la página principal, algo que solo se hace con autorización del responsable. Estos vectores forman parte del análisis completo de la plataforma.
¿La nota de esta página incluye TLS y correo?
No. El diagnóstico completo ejecuta TLS, cabeceras HTTP y correo en el dominio indicado. En esta página solo se ejecuta el análisis de cabeceras, y la nota refleja ese resultado. En el diagnóstico completo, cada hallazgo muestra de qué verificación viene. Es común que una aplicación con cabeceras correctas esté en un dominio sin DMARC, lo que permite enviar correos en nombre de la empresa.