Vai al contenuto principale

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

Try live target:

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).
Security standard reference

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 nameSpecificationRecommended directiveRisk if missing
Strict-Transport-Security (HSTS)RFC 6797max-age=31536000; includeSubDomains; preloadCritical
Content-Security-Policy (CSP)W3C CSP Level 3default-src 'self'; script-src 'self' https:; object-src 'none';Critical
X-Frame-OptionsRFC 7034DENY or SAMEORIGINHigh
X-Content-Type-OptionsFetch SpecnosniffHigh
Referrer-PolicyW3C Referrer Policystrict-origin-when-cross-originMedium
Permissions-PolicyW3C Draftcamera=(), microphone=(), geolocation=()Medium
Cross-Origin-Opener-Policy (COOP)HTML Specsame-originLow
Enterprise network architecture

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:

HTTP 200 OK
Authenticated Browsing & Portal Assets

The client has authenticated or is loading portal stylesheets/scripts. Requires correct Content-Type.

HTTP 302 Found
Legacy Captive Portal Interception

Standard HTTP redirect sent by wireless controllers to route unauthenticated devices to splash page.

HTTP 307 Temporary Redirect
Method-Preserving Redirection

Ensures POST requests and payload bodies remain intact without downgrading to GET requests.

RFC 8908 JSON
application/captive+json Endpoint

Returns machine-readable JSON indicating captive state, login URL, and seconds remaining without HTTP interception.

Technical FAQ

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.

Related network diagnostic tools

Explore companion WiFi and infrastructure tools

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 demo
Free Desktop App

Netforge Network Multi-Tool

Run offline network health checks, path analysis, and latency diagnostic scans directly from your desktop.

Download Multi-Tool