Passer au contenu principal

Vérificateur d'en-têtes de réponse HTTP

Inspectez les en-têtes de réponse HTTP en direct, évaluez les en-têtes de sécurité OWASP (HSTS, CSP, X-Frame-Options) et auditez les en-têtes de redirection de portail captif.

Vérifier les en-têtes de réponse HTTP d'une URL

Try live target:

Probes are executed server-side from Purple edge network infrastructure. Response headers represent external client inspection without browser cache interference.

Pourquoi les en-têtes de réponse sont essentiels pour la sécurité web et les portails captifs

Les en-têtes de réponse HTTP contrôlent les politiques de mise en cache, les comportements de redirection, les types MIME de contenu et la posture de sécurité défensive des applications web et des portails captifs. Pour les pages de démarrage des établissements et les réseaux WiFi invité, des en-têtes de sécurité manquants ou un préchargement HSTS mal configuré peuvent déclencher de graves avertissements SSL dans le navigateur ou bloquer la redirection vers le réseau captif. Cet outil effectue une analyse côté serveur de n'importe quelle URL cible, analyse tous les en-têtes de réponse bruts et évalue les principales protections de sécurité OWASP.

Ce que cet outil analyse

  • Les en-têtes de sécurité critiques, notamment HSTS, Content-Security-Policy, X-Frame-Options et X-Content-Type-Options.
  • Les codes d'état HTTP, les emplacements de redirection (301, 302, 307, 308) et la compatibilité avec l'API de portail captif (RFC 8908).
  • La divulgation des logiciels serveurs, les en-têtes de mise en cache (Cache-Control, ETag) et les politiques de confidentialité (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

Foire aux questions

Pourquoi le préchargement HSTS bloque-t-il les pages de connexion de portail captif sur les réseaux WiFi invité publics ?

Le protocole HTTP Strict Transport Security (HSTS) avec la directive preload indique aux navigateurs de refuser les connexions HTTP non chiffrées et d'interdire le contournement des erreurs de certificat. Lorsqu'un invité se connecte au WiFi et tente d'ouvrir un domaine préchargé HSTS (comme google.com), l'interception HTTP du contrôleur sans fil ne peut pas présenter de certificat valide pour ce domaine. Le navigateur affiche alors un avertissement SSL bloquant au lieu de rediriger vers le portail captif. Les réseaux modernes utilisent l'API de portail captif RFC 8908 ou les domaines de test de portail captif d'Apple/Android (comme captive.apple.com) qui omettent intentionnellement le HSTS.

Quels en-têtes Content-Security-Policy (CSP) sont recommandés pour les pages de démarrage de portail captif ?

Les pages de démarrage de portail captif nécessitent une CSP équilibrée qui autorise les ressources d'authentification essentielles tout en empêchant le cross-site scripting (XSS). La politique doit autoriser les scripts et les styles provenant de CDN de confiance et de fournisseurs d'identité de connexion sociale (tels que Google, Apple et Microsoft), tout en restreignant default-src à 'self' et en interdisant l'exécution de scripts inline non approuvés. De plus, les domaines de redirection d'authentification sociale doivent être autorisés dans le Walled Garden du contrôleur réseau.

Comment l'en-tête X-Frame-Options protège-t-il les formulaires de connexion WiFi invité contre le clickjacking ?

L'en-tête X-Frame-Options: DENY ou SAMEORIGIN (ainsi que la directive moderne CSP frame-ancestors) empêche les sites web tiers malveillants d'afficher le formulaire de connexion du portail captif dans une iframe invisible. Cela élimine les attaques par clickjacking où les attaquants incitent les visiteurs à soumettre leurs identifiants de connexion ou leurs jetons d'autorisation sociale.

Quelle est la différence entre les redirections HTTP 302 et HTTP 307 dans les flux de travail de portail captif ?

Une redirection HTTP 302 Found est couramment utilisée par les contrôleurs réseau existants pour rediriger les requêtes HTTP initiales vers l'URL de la page de démarrage, mais les clients peuvent remplacer les requêtes POST par des requêtes GET. Une redirection HTTP 307 Temporary Redirect garantit que la méthode HTTP et le corps de la requête restent inchangés pendant la redirection. Pour les réseaux captifs modernes, la RFC 8908 fournit un point de terminaison JSON standardisé qui élimine complètement l'interception HTTP.

Pourquoi l'en-tête X-Content-Type-Options: nosniff est-il essentiel pour les applications web d'entreprise ?

L'en-tête X-Content-Type-Options: nosniff force les navigateurs à respecter strictement le type MIME déclaré dans l'en-tête Content-Type. Cela empêche les attaques par MIME-sniffing où des fichiers téléchargés par l'utilisateur ou des fragments de texte malveillants sont exécutés en tant que JavaScript ou CSS exécutables dans des navigateurs vulnérables.

Comment les en-têtes Permissions-Policy améliorent-ils la confidentialité des visiteurs sur les portails WiFi publics ?

Permissions-Policy (anciennement Feature-Policy) permet aux exploitants de sites de désactiver les API matérielles sensibles telles que la caméra, le microphone, la géolocalisation et les demandes de paiement dans le contexte du navigateur. La désactivation des fonctionnalités d'appareil inutilisées sur les pages de destination WiFi invité rassure les visiteurs sur le fait que le portail respecte les normes de confidentialité des données.

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