Gratuit · sans compte

Vérificateur d’en-têtes de sécurité HTTP

Vérifiez en ligne les en-têtes de sécurité HTTP d’un site public. Saisissez un domaine pour voir comment huit en-têtes de sécurité essentiels sont évalués sur la réponse finale et, lorsqu’elle est affichée, la valeur observée.

Un contrôle gratuit des paramètres publics du site. Votre site web n’est pas modifié.

Sans inscription Aucun trafic destructif Contrôles de sites web publics
Référence des en-têtes

Ce que fait chaque en-tête et comment il est évalué

Le vérificateur lit ces en-têtes sur une seule réponse. La plupart des lignes sont des contrôles de présence : un en-tête envoyé compte, et sa valeur est affichée quand elle est disponible pour que vous jugiez si elle convient à votre site.

En-têteRôleBonne configurationÉvaluation par ce vérificateur
Strict-Transport-SecurityFait passer d’eux-mêmes en HTTPS les navigateurs qui reviennent, avant qu’une requête parte en HTTP non chiffré.Un max-age long (180 jours ou plus) une fois la montée progressive terminée ; le guide détaille les étapes.Absent sur une cible HTTPS : moyen. Non évalué si vous saisissez une adresse http://.
Content-Security-PolicyDonne au navigateur une liste de sources autorisées pour le code et le contenu de la page.Une politique construite à partir des ressources que vos pages utilisent réellement, sans larges exceptions pour les scripts.Absent : moyen. La valeur est affichée mais pas analysée.
X-Frame-Options · frame-ancestorsEmpêche d’autres sites d’afficher votre page dans un de leurs cadres.frame-ancestors dans votre CSP, avec X-Frame-Options en repli pour les anciens navigateurs.Aucun des deux : moyen.
X-Content-Type-OptionsFait respecter par le navigateur le type de contenu déclaré de chaque réponse.La seule valeur nosniff.Absent ou toute autre valeur : faible.
Referrer-PolicyLimite la partie de l’adresse de votre page que voient d’autres sites quand les visiteurs suivent vos liens.Une politique au moins aussi stricte que la valeur par défaut actuelle des navigateurs.Absent : faible.
Access-Control-Allow-OriginDécide quels scripts d’autres sites peuvent lire vos réponses.Non envoyé sur les pages ordinaires, ou limité à une seule origine de confiance.Un joker (*) : moyen.
Server · X-Powered-ByAnnonce le logiciel derrière la réponse.Supprimé, ou réduit à une valeur générique.Tout en-tête Server ou X-Powered-By : faible, même sans numéro de version. Seuls les noms de technologies reconnues sont affichés.
Set-CookieDépose des cookies ; ses attributs décident quels scripts peuvent les lire et quand ils sont envoyés.Des cookies de session cachés aux scripts et envoyés uniquement en HTTPS.Un cookie de cette réponse sans HttpOnly, ou sans Secure en HTTPS : moyen. SameSite n’est pas vérifié et les valeurs des cookies ne sont jamais affichées.

Permissions-Policy et Cross-Origin-Opener-Policy ne sont pas évalués sur cette page. Le snapshot de préparation ne les compte que dans sa note de durcissement distincte.

Comment corriger

Comment ajouter ces en-têtes sur votre serveur

Définissez chaque en-tête dans une seule couche qui répond à toutes les requêtes : le serveur web, le CDN ou la plateforme d’hébergement. Commencez par les valeurs ci-dessous, puis renforcez-les par étapes en testant vos pages clés.

Valeurs de départ sûres

  1. 01Strict-Transport-Security: max-age=300Envoyez-le uniquement sur les réponses HTTPS ; les navigateurs l’ignorent en HTTP non chiffré. Augmentez max-age par paliers, par exemple à une semaine, un mois puis un an (31536000), et vérifiez votre site à chaque palier. N’ajoutez includeSubDomains que si tous les sous-domaines servent HTTPS, et preload qu’après avoir lu les exigences de hstspreload.org, car sortir de la liste de préchargement prend des mois.
  2. 02Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'Report-Only ne bloque rien : le navigateur signale ce que la politique bloquerait, dans la console ou vers un point de collecte de rapports si vous en ajoutez un. Ouvrez vos pages clés, ajoutez les sources qu’elles utilisent réellement, puis envoyez la même politique en Content-Security-Policy. Évitez 'unsafe-inline' pour les scripts ; les nonces ou les hachages sont l’option la plus stricte.
  3. 03frame-ancestors 'self' · X-Frame-Options: SAMEORIGINframe-ancestors dans une Content-Security-Policy appliquée décide quels sites peuvent afficher vos pages dans un cadre. X-Frame-Options couvre les anciens navigateurs et bloque tant que votre CSP reste en Report-Only. Utilisez 'none' et DENY si vos pages ne sont jamais intégrées, gardez les deux valeurs cohérentes et envoyez frame-ancestors en en-tête, car les navigateurs l’ignorent dans une balise meta.
  4. 04X-Content-Type-Options: nosniffEnvoyez la valeur unique nosniff sur chaque réponse. Les navigateurs refusent alors les scripts et feuilles de style servis avec un mauvais Content-Type : vérifiez d’abord que votre serveur déclare correctement les fichiers JavaScript et CSS.
  5. 05Referrer-Policy: strict-origin-when-cross-originLes autres sites ne reçoivent que votre origine, jamais l’adresse complète de la page, et rien du tout quand un lien mène de HTTPS vers HTTP. Les navigateurs actuels l’utilisent déjà par défaut ; l’envoyer garde le même comportement partout. Choisissez same-origin ou no-referrer si vos URL contiennent des données privées.
  6. 06Permissions-Policy: camera=(), microphone=(), geolocation=()Une liste vide () désactive une fonctionnalité pour votre page et pour chaque cadre qu’elle intègre. N’indiquez que les fonctionnalités que votre site n’utilise jamais, puis testez les pages avec cartes, appels vidéo ou widgets de paiement.

Exemples prêts à copier par plateforme

Chaque exemple définit les mêmes valeurs de départ. Les plateformes d’hébergement envoient peut-être déjà Strict-Transport-Security, c’est pourquoi les exemples Vercel, Netlify et Next.js ne l’incluent pas ; vérifiez la réponse réelle et ajoutez-le seulement s’il manque.

nginx

Placez les lignes dans le bloc server qui sert HTTPS. Le paramètre always les ajoute aussi aux réponses d’erreur. Un bloc location qui a ses propres lignes add_header abandonne toutes les add_header héritées du bloc server : répétez l’ensemble à cet endroit ou gardez-le dans un seul fichier include.

# In the server block that serves HTTPS (listen 443 ssl)
add_header Strict-Transport-Security "max-age=300" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Apache

Activez mod_headers et ajoutez les lignes au virtual host du port 443, ou à un fichier .htaccess là où AllowOverride FileInfo est actif. Header always set couvre aussi les réponses d’erreur et les redirections.

# <VirtualHost *:443> or .htaccess; needs mod_headers (Debian/Ubuntu: a2enmod headers)
Header always set Strict-Transport-Security "max-age=300"
Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

Cloudflare

Dans le tableau de bord, créez une Response Header Transform Rule pour votre nom d’hôte et ajoutez chaque en-tête avec l’opération Set static, qui remplace un en-tête du même nom venant de votre origine. HSTS a son propre réglage sous SSL/TLS, Edge Certificates ; utilisez ce réglage ou la règle, pas les deux. Les noms des menus peuvent varier selon la version du tableau de bord.

Rule type   Response Header Transform Rule
When        Hostname equals example.com
Then        Set static, one row per header:
  X-Content-Type-Options               nosniff
  Referrer-Policy                      strict-origin-when-cross-origin
  X-Frame-Options                      SAMEORIGIN
  Permissions-Policy                   camera=(), microphone=(), geolocation=()
  Content-Security-Policy-Report-Only  default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

HSTS        SSL/TLS > Edge Certificates > HTTP Strict Transport Security (HSTS)

Vercel

Ajoutez une entrée headers à vercel.json à la racine du projet. Le motif source /(.*) correspond à tous les chemins ; restreignez-le si certaines routes ont besoin d’une autre politique.

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Content-Security-Policy-Report-Only", "value": "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" },
        { "key": "X-Frame-Options", "value": "SAMEORIGIN" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" }
      ]
    }
  ]
}

Netlify

Créez un fichier nommé _headers dans le répertoire de publication, le dossier que Netlify déploie. Chaque ligne de chemin, comme /*, est suivie de lignes indentées Nom: valeur. Les mêmes règles peuvent aussi aller dans netlify.toml sous [[headers]].

/*
  Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'
  X-Frame-Options: SAMEORIGIN
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()

Next.js

Renvoyez les en-têtes depuis la fonction async headers() de next.config.js ; le source '/:path*' couvre toutes les routes. headers() ne s’exécute pas pour un export statique (output: 'export') : définissez alors les en-têtes chez l’hébergeur qui sert les fichiers exportés.

// next.config.js
const securityHeaders = [
  { key: 'Content-Security-Policy-Report-Only', value: "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" },
  { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
];

module.exports = {
  async headers() {
    return [{ source: '/:path*', headers: securityHeaders }];
  },
};

Après le déploiement, relancez le vérificateur : il lit la réponse finale et montre donc ce que votre CDN ou votre plateforme envoie réellement. Ouvrez ensuite une page d’erreur et un fichier statique dans les outils de développement du navigateur, car les en-têtes ne sont souvent définis que pour certaines réponses.

Lire le résultat

Comment lire chaque statut.

  1. 01RéussiL’en-tête a été trouvé et satisfait le contrôle de présence.
  2. 02Faible · Moyen · ÉlevéUn élément manque ou est configuré d’une façon que ce contrôle signale. Le niveau est le même que dans le snapshot complet.
  3. 03ObservéUne valeur a été relevée, mais le contrôle n’a produit ni réussite ni constat.
  4. 04Rien observéLe contrôle a été exécuté mais il n’y avait rien à relever, par exemple aucun cookie dans la réponse.
  5. 05Non applicableLe contrôle ne s’applique pas, par exemple HSTS quand vous saisissez une adresse http://.
  6. 06Non mesuréAucune réponse exploitable n’a été reçue, le contrôle n’est donc pas compté comme réussi.
Périmètre

Ce que ce vérificateur ne fait pas.

  1. 01Il ne demande que la page d’accueil de l’origine saisie. Chemins et paramètres de requête sont ignorés, et aucune autre page n’est demandée.
  2. 02Il vérifie surtout la présence d’un en-tête, pas si sa valeur convient à votre site.
  3. 03Il teste la redirection de HTTP vers HTTPS uniquement si vous saisissez l’adresse http:// ; cette exécution saute TLS et ne signale pas l’absence de HSTS.
  4. 04Ce n’est ni un scan de vulnérabilités ni un test d’intrusion, et il n’envoie aucun trafic d’attaque.
  5. 05Le résultat est une vue ponctuelle d’une réponse ; une règle CDN ou une autre page peut envoyer d’autres en-têtes.
FAQ

Questions sur le contrôle des en-têtes.

Pourquoi Server: nginx est-il signalé sans version ?

Tout en-tête Server ou X-Powered-By est évalué faible, car le nom seul indique aux visiteurs quel logiciel fait tourner le site. Supprimez l’en-tête ou réduisez-le à une valeur générique si votre plateforme le permet.

Pourquoi le résultat diffère-t-il de la configuration de mon serveur ?

Le vérificateur lit la réponse qu’il reçoit après cinq redirections au plus. Ce sont les en-têtes ajoutés ou retirés par un CDN, un proxy ou la plateforme d’hébergement qui comptent, et les règles de CDN, de proxy ou de protection anti-bots peuvent répondre aux navigateurs autrement qu’au vérificateur.

Puis-je vérifier un site qui ne m’appartient pas ?

Oui. Le contrôle des en-têtes lit une réponse ordinaire que le site envoie déjà à chaque visiteur ; l’exécution complète envoie quelques autres requêtes ordinaires pour les autres contrôles. Les modules protégés et les audits complets exigent une cible vérifiée ou une autorisation explicite.

Est-ce un scan de vulnérabilités ?

Non. C’est un contrôle passif des en-têtes de réponse, ni un scan de vulnérabilités ni un test d’intrusion, et il ne prouve pas qu’un site soit sûr.

Pourquoi mes en-têtes manquent-ils sur certaines réponses ?

Les en-têtes ne sont souvent définis que pour une route, un type de fichier ou un code de statut. Dans nginx, add_header sans always ignore les réponses d’erreur, et un bloc location avec ses propres lignes add_header abandonne celles du bloc server. Les fichiers statiques, les routes d’API et les pages servies par un autre service peuvent aussi échapper à la règle qui les ajoute.

Puis-je définir le même en-tête dans l’application et sur le CDN ?

Définissez chaque en-tête dans une seule couche. Si deux couches l’ajoutent, le navigateur peut recevoir deux valeurs : avec Content-Security-Policy, chaque politique envoyée s’applique, donc le résultat est plus strict que chacune d’elles, et avec Strict-Transport-Security, seul le premier en-tête est utilisé.

Dois-je inscrire mon domaine sur la liste de préchargement HSTS ?

Seulement si chaque sous-domaine, actuel et futur, peut servir HTTPS. La liste exige un max-age d’au moins un an avec includeSubDomains et preload ; les navigateurs utilisent ensuite HTTPS pour le domaine avant même la première visite, et un retrait de la liste peut mettre des mois à atteindre les utilisateurs. Un max-age long sans preload couvre déjà les visiteurs qui reviennent.

Étape suivante

Transformez les constats en un plan de correction clair.