Verificatore degli header di risposta HTTP
Ispeziona gli header di risposta HTTP in tempo reale, valuta gli header di sicurezza OWASP (HSTS, CSP, X-Frame-Options) e controlla gli header di reindirizzamento del portale captive.
Verifica gli header di risposta HTTP di un URL
Probes are executed server-side from Purple edge network infrastructure. Response headers represent external client inspection without browser cache interference.
Perché gli header di risposta sono importanti per la sicurezza web e i portali captive
Gli header di risposta HTTP controllano le policy di caching, i comportamenti di reindirizzamento, i tipi MIME dei contenuti e la postura di sicurezza difensiva delle applicazioni web e dei portali captive. Per le splash page delle location e le reti WiFi per ospiti, la mancanza di header di sicurezza o una configurazione errata del precaricamento HSTS possono attivare gravi avvisi SSL del browser o interrompere il reindirizzamento della rete captive. Questo strumento esegue una scansione lato server di qualsiasi URL di destinazione, analizza tutti gli header di risposta grezzi e valuta le principali protezioni di sicurezza OWASP.
Cosa analizza questo strumento
- Header di sicurezza critici tra cui HSTS, Content-Security-Policy, X-Frame-Options e X-Content-Type-Options.
- Codici di stato HTTP, posizioni di reindirizzamento (301, 302, 307, 308) e compatibilità con le API del portale captive (RFC 8908).
- Divulgazione del software del server, header di caching (Cache-Control, ETag) e informative sulla privacy (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.
Domande frequenti
Perché il precaricamento HSTS interrompe le pagine di login del portale captive sulle reti WiFi per ospiti pubbliche?
HTTP Strict Transport Security (HSTS) con la direttiva preload indica ai browser di rifiutare le connessioni HTTP non crittografate e di non consentire l'esclusione degli errori di certificato. Quando un ospite si connette al WiFi e tenta di aprire un dominio precaricato HSTS (come google.com), l'intercettazione HTTP del controller wireless non può presentare un certificato valido per quel dominio. Il browser mostra un avviso SSL bloccante invece di reindirizzare al portale captive. Le reti moderne utilizzano l'API del portale captive RFC 8908 o i domini di test del portale captive di Apple/Android (come captive.apple.com) che omettono intenzionalmente l'HSTS.
Quali header Content-Security-Policy (CSP) sono consigliati per le splash page del portale captive?
Le splash page del portale captive richiedono una CSP bilanciata che consenta gli asset di autenticazione essenziali impedendo al contempo il cross-site scripting (XSS). La policy dovrebbe consentire script e stili da CDN affidabili e provider di identità per il social login (come Google, Apple e Microsoft), limitando al contempo default-src 'self' e vietando l'esecuzione di script inline non attendibili. Inoltre, i domini di reindirizzamento dell'autenticazione social devono essere inseriti nella whitelist del Walled Garden del controller di rete.
In che modo X-Frame-Options protegge i moduli di login del WiFi per ospiti dal clickjacking?
L'header X-Frame-Options: DENY o SAMEORIGIN (e la moderna direttiva CSP frame-ancestors) impedisce ai siti web di terze parti dannosi di caricare il modulo di login del portale captive all'interno di un iframe invisibile. Ciò elimina gli attacchi di clickjacking in cui i malintenzionati ingannano i visitatori spingendoli a inviare credenziali di accesso o token di autorizzazione social.
Qual è la differenza tra i reindirizzamenti HTTP 302 e HTTP 307 nei flussi di lavoro del portale captive?
Un reindirizzamento HTTP 302 Found viene comunemente utilizzato dai controller di rete legacy per reindirizzare le richieste HTTP iniziali all'URL della splash page, ma i client potrebbero convertire le richieste POST in GET. Un reindirizzamento temporaneo HTTP 307 garantisce che il metodo HTTP e il corpo della richiesta rimangano invariati durante il reindirizzamento. Per le moderne reti captive, la specifica RFC 8908 fornisce un endpoint JSON standardizzato che elimina completamente l'intercettazione HTTP.
Perché X-Content-Type-Options: nosniff è essenziale per le applicazioni web aziendali?
L'header X-Content-Type-Options: nosniff costringe i browser a rispettare rigorosamente il tipo MIME dichiarato nell'header Content-Type. Ciò previene gli attacchi di MIME-sniffing in cui i file caricati dagli utenti o frammenti di testo dannosi vengono eseguiti come JavaScript o CSS eseguibili nei browser vulnerabili.
In che modo gli header Permissions-Policy migliorano la privacy dei visitatori sui portali WiFi pubblici?
Permissions-Policy (precedentemente Feature-Policy) consente ai gestori dei siti di disabilitare API hardware sensibili come fotocamera, microfono, geolocalizzazione e richieste di pagamento all'interno del contesto del browser. La disattivazione delle funzionalità del dispositivo non utilizzate sulle landing page del WiFi per ospiti rassicura i visitatori sul fatto che il portale rispetta gli standard di privacy dei dati.
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