Comprobador de cabeceras de respuesta HTTP
Inspeccione cabeceras de respuesta HTTP en tiempo real, evalúe cabeceras de seguridad OWASP (HSTS, CSP, X-Frame-Options) y audite las cabeceras de redirección del portal cautivo.
Compruebe las cabeceras de respuesta HTTP de una URL
Probes are executed server-side from Purple edge network infrastructure. Response headers represent external client inspection without browser cache interference.
Por qué las cabeceras de respuesta son importantes para la seguridad web y los portales cautivos
Las cabeceras de respuesta HTTP controlan las políticas de almacenamiento en caché, los comportamientos de redirección, los tipos MIME de contenido y la postura de seguridad defensiva de las aplicaciones web y los portales cautivos. En el caso de las páginas de inicio de recintos y las redes WiFi para invitados, la falta de cabeceras de seguridad o una precarga de HSTS mal configurada pueden provocar advertencias graves de SSL en el navegador o interrumpir la redirección de la red cautiva. Esta herramienta realiza un análisis del lado del servidor de cualquier URL de destino, analiza todas las cabeceras de respuesta sin procesar y califica las protecciones de seguridad clave de OWASP.
Qué analiza esta herramienta
- Cabeceras de seguridad críticas, incluyendo HSTS, Content-Security-Policy, X-Frame-Options y X-Content-Type-Options.
- Códigos de estado HTTP, ubicaciones de redirección (301, 302, 307, 308) y compatibilidad con la API del portal cautivo (RFC 8908).
- Divulgación de software del servidor, cabeceras de almacenamiento en caché (Cache-Control, ETag) y políticas de privacidad (Referrer-Policy, Permissions-Policy).
OWASP security headers benchmark and directives
Web servers and captive portal splash pages must deploy hardening headers to prevent data interception, credential theft, and script injection. The table below outlines the core security headers defined by OWASP and IETF standards:
| Header name | Specification | Recommended directive | Risk if missing |
|---|---|---|---|
| Strict-Transport-Security (HSTS) | RFC 6797 | max-age=31536000; includeSubDomains; preload | Critical |
| Content-Security-Policy (CSP) | W3C CSP Level 3 | default-src 'self'; script-src 'self' https:; object-src 'none'; | Critical |
| X-Frame-Options | RFC 7034 | DENY or SAMEORIGIN | High |
| X-Content-Type-Options | Fetch Spec | nosniff | High |
| Referrer-Policy | W3C Referrer Policy | strict-origin-when-cross-origin | Medium |
| Permissions-Policy | W3C Draft | camera=(), microphone=(), geolocation=() | Medium |
| Cross-Origin-Opener-Policy (COOP) | HTML Spec | same-origin | Low |
Captive portal HTTP response codes and redirect mechanics
Captive network assistants (such as Apple iOS CNA, Android CaptivePortalLogin, and Windows NCSI) probe specific HTTP endpoints upon WiFi association. Understanding HTTP response codes ensures seamless visitor onboarding without triggering certificate warnings:
The client has authenticated or is loading portal stylesheets/scripts. Requires correct Content-Type.
Standard HTTP redirect sent by wireless controllers to route unauthenticated devices to splash page.
Ensures POST requests and payload bodies remain intact without downgrading to GET requests.
Returns machine-readable JSON indicating captive state, login URL, and seconds remaining without HTTP interception.
Preguntas frecuentes
¿Por qué la precarga de HSTS interrumpe las páginas de inicio de sesión del portal cautivo en redes WiFi para invitados públicas?
HTTP Strict Transport Security (HSTS) con la directiva preload indica a los navegadores que rechacen conexiones HTTP no cifradas y no permitan omitir errores de certificado. Cuando un invitado se conecta a la red WiFi e intenta abrir un dominio precargado con HSTS (como google.com), la intercepción HTTP del controlador inalámbrico no puede presentar un certificado válido para ese dominio. El navegador muestra una advertencia de SSL crítica en lugar de redirigir al portal cautivo. Las redes modernas utilizan la API de portal cautivo de la norma RFC 8908 o dominios de prueba de portal cautivo de Apple/Android (como captive.apple.com) que omiten intencionadamente HSTS.
¿Qué cabeceras de Content-Security-Policy (CSP) se recomiendan para las páginas de inicio de los portales cautivos?
Las páginas de inicio de los portales cautivos requieren una CSP equilibrada que permita los recursos de autenticación esenciales y, al mismo tiempo, evite el cross-site scripting (XSS). La política debe permitir scripts y estilos de CDN de confianza y proveedores de identidad de inicio de sesión social (como Google, Apple y Microsoft), al tiempo que restringe default-src 'self' y prohíbe la ejecución de scripts en línea no confiables. Además, los dominios de redirección de autenticación social deben incluirse en la lista blanca (Walled Garden) del controlador de red.
¿Cómo protege X-Frame-Options los formularios de inicio de sesión de WiFi para invitados contra el clickjacking?
La cabecera X-Frame-Options: DENY o SAMEORIGIN (y la directiva moderna frame-ancestors de CSP) evita que sitios web de terceros maliciosos rendericen el formulario de inicio de sesión del portal cautivo dentro de un iframe invisible. Esto elimina los ataques de clickjacking en los que los atacantes engañan a los visitantes para que envíen credenciales de inicio de sesión o tokens de autorización social.
¿Cuál es la diferencia entre las redirecciones HTTP 302 y HTTP 307 en los flujos de trabajo de los portales cautivos?
Los controladores de red heredados suelen utilizar una redirección HTTP 302 Found para redirigir las solicitudes HTTP iniciales a la URL de la página de inicio, pero los clientes pueden cambiar las solicitudes POST a GET. Una redirección temporal HTTP 307 garantiza que el método HTTP y el cuerpo de la solicitud permanezcan sin cambios durante la redirección. Para las redes cautivas modernas, la norma RFC 8908 proporciona un endpoint JSON estandarizado que elimina por completo la intercepción HTTP.
¿Por qué es esencial X-Content-Type-Options: nosniff para las aplicaciones web empresariales?
La cabecera X-Content-Type-Options: nosniff obliga a los navegadores a adherirse estrictamente al tipo MIME declarado en la cabecera Content-Type. Esto evita los ataques de MIME-sniffing en los que los archivos cargados por los usuarios o los fragmentos de texto maliciosos se ejecutan como JavaScript o CSS ejecutable en navegadores vulnerables.
¿Cómo mejoran las cabeceras Permissions-Policy la privacidad de los visitantes en los portales WiFi públicos?
Permissions-Policy (anteriormente Feature-Policy) permite a los operadores de sitios desactivar API de hardware sensibles, como la cámara, el micrófono, la geolocalización y la solicitud de pago dentro del contexto del navegador. Desactivar las funciones del dispositivo que no se utilizan en las páginas de destino de WiFi para invitados garantiza a los visitantes que el portal respeta los estándares de privacidad de datos.
Explore companion WiFi and infrastructure tools
SSL Certificate Checker →
Inspect live TLS certificate validity, expiration dates, and Certificate Authority trust chains.
DNS Record Lookup →
Query A, AAAA, MX, TXT (SPF/DMARC), and CAA records across global DNS resolvers.
Walled Garden Generator →
Generate pre-tested walled garden allowlists for Meraki, Aruba, Ruckus, and UniFi controllers.
Access Point Calculator →
Estimate AP capacity, RF attenuation, and PoE power budgets for venue wireless deployments.
Securing captive portal traffic across enterprise networks?
Headers are one defensive layer. Purple manages enterprise captive portal hosting, SSL/TLS certificates, and compliant redirect architecture across Cisco Meraki, HPE Aruba, Ruckus, and Juniper Mist.
Book a 20-min demoNetforge Network Multi-Tool
Run offline network health checks, path analysis, and latency diagnostic scans directly from your desktop.
Download Multi-Tool