# Comment améliorer votre note de headers de sécurité (/fr/blog/improve-security-headers-grade)



Un scanner vous a donné une note de headers de sécurité basse, et vous cherchez maintenant quels headers poser, et comment. Cette note est un score de checklist : un outil lit vos headers de réponse, coche chaque header recommandé comme présent ou manquant, puis évalue la qualité de configuration de ceux qui sont là. Pour la relever, il faut envoyer le bon jeu de headers avec les bonnes valeurs. Voici ce jeu, le rôle de chaque header et la valeur à déployer, avec les correctifs plus poussés en lien à chaque étape.

Chaque scanner pondère à sa façon. [securityheaders.com](https://securityheaders.com/) vérifie une liste fixe de headers et vous dégrade pour ceux qui manquent. [Mozilla Observatory](https://developer.mozilla.org/en-US/observatory) (l'Observatory de MDN) note la CSP plus strictement et récompense une politique sans `'unsafe-inline'`. Les agences de notation posent leur propre vocabulaire sur les mêmes vérifications. Les headers ci-dessous les couvrent toutes.

## Les headers qu'un scanner note [#les-headers-quun-scanner-note]

Six headers font presque toute la note. Posez-les, configurez-les correctement, et un A devient atteignable.

### La politique de sécurité du contenu, le facteur unique le plus lourd [#la-politique-de-sécurité-du-contenu-le-facteur-unique-le-plus-lourd]

Une politique de sécurité du contenu (CSP) indique au navigateur quels scripts, styles et autres ressources une page peut charger. C'est le header auquel la plupart des scanners donnent le plus de poids, et une CSP stricte sans `'unsafe-inline'` est ce qui décroche la meilleure note sur un scanner qui sait lire la CSP, comme Mozilla Observatory.

```http
Content-Security-Policy:
    default-src 'self';
    script-src 'nonce-{RANDOM}' 'strict-dynamic';
    object-src 'none';
    base-uri 'none';
    frame-ancestors 'none'
```

Une CSP est aussi le header le plus susceptible de casser la page si vous l'écrivez au jugé : déployez-la d'abord en report-only, collectez ce que le trafic réel bloque, puis appliquez-la. La méthode complète est dans [comment construire une CSP solide, étape par étape](/fr/blog/how-to-build-a-strong-csp), et le mot-clé à retirer en premier est traité dans [pourquoi ne jamais utiliser unsafe-inline dans une CSP](/fr/blog/unsafe-inline-csp).

### Strict-Transport-Security (HSTS), imposer HTTPS [#strict-transport-security-hsts-imposer-https]

`Strict-Transport-Security` indique au navigateur de ne joindre votre site qu'en HTTPS, ce qui referme la faille de la toute première requête partie en clair. Envoyez un long `max-age` et incluez les sous-domaines. N'ajoutez `preload` que lorsque vous êtes prêt à engager le domaine sur la liste de preload du navigateur, car c'est difficile à annuler.

```http
Strict-Transport-Security: max-age=63072000; includeSubDomains
```

### X-Content-Type-Options, stopper le MIME sniffing [#x-content-type-options-stopper-le-mime-sniffing]

`X-Content-Type-Options: nosniff` empêche le navigateur de deviner le type de contenu déclaré d'une réponse, ce qui est justement ainsi que certains fichiers uploadés finissent exécutés comme des scripts. Il n'a qu'une seule valeur et aucun remplaçant moderne : posez-le partout.

```http
X-Content-Type-Options: nosniff
```

### Contrôle du framing, préférez frame-ancestors [#contrôle-du-framing-préférez-frame-ancestors]

La protection anti-clickjacking décide qui peut embarquer votre page dans une frame. Le contrôle moderne est la directive CSP [`frame-ancestors`](/fr/docs/web-security/policies/content-security-policy/directives/frame-ancestors), qui gère plusieurs origines et `'none'`. L'ancien header `X-Frame-Options` satisfait encore certaines vérifications de scanner et sert de repli pour les navigateurs très anciens, mais c'est `frame-ancestors` qui fait le travail aujourd'hui. Les raisons de la disparition de l'ancien header sont détaillées dans [les headers de sécurité hérités que vous pouvez retirer](/fr/blog/legacy-security-headers-to-retire).

```http
Content-Security-Policy: frame-ancestors 'none'
```

### Referrer-Policy, limiter ce que vous laissez fuir [#referrer-policy-limiter-ce-que-vous-laissez-fuir]

`Referrer-Policy` contrôle quelle part de l'URL courante est envoyée dans le header `Referer` quand un utilisateur quitte la page ou qu'une page charge une ressource. Une valeur par défaut raisonnable ne transmet que l'origine sur les requêtes cross-origin, et le chemin complet en same-origin.

```http
Referrer-Policy: strict-origin-when-cross-origin
```

### Permissions-Policy, désactiver les fonctionnalités que vous n'utilisez pas [#permissions-policy-désactiver-les-fonctionnalités-que-vous-nutilisez-pas]

`Permissions-Policy` contrôle l'accès aux fonctionnalités du navigateur comme la caméra, le microphone et la géolocalisation. Désactiver celles que votre site n'utilise pas réduit ce qu'un script injecté peut atteindre. C'est le successeur standardisé du `Feature-Policy` déprécié, expliqué dans [Permissions-Policy expliqué](/fr/blog/permissions-policy-explained).

```http
Permissions-Policy: geolocation=(), camera=(), microphone=()
```

## L'ordre dans lequel les corriger [#lordre-dans-lequel-les-corriger]

Posez d'abord les headers à faible risque, car ils ne peuvent pas casser la page : `X-Content-Type-Options`, `Referrer-Policy`, `Strict-Transport-Security` et `Permissions-Policy` sont des ajouts d'une ligne que vous pouvez déployer aujourd'hui. Ils feront bouger la note immédiatement.

Gardez la CSP pour la fin : c'est la seule qui exige le cycle report-only, collecte, application, pour ne pas casser le trafic réel. C'est aussi le critère qui pèse le plus lourd, elle mérite donc ce soin supplémentaire.

```mermaid
flowchart LR
  A["Quick wins<br/>nosniff, Referrer-Policy,<br/>HSTS, Permissions-Policy"] --> B["CSP via<br/>Report-Only"]
  B --> C["Collect"]
  C --> D["Enforce"]
```

## Si votre note basse vient d'une agence de notation [#si-votre-note-basse-vient-dune-agence-de-notation]

Les agences de notation de sécurité évaluent les mêmes headers, mais publient leurs propres noms de findings ; le correctif, lui, reste le même jeu de headers bien configuré. Si votre finding vient de l'une d'elles, les guides par agence rattachent chaque finding à un changement de header :

* [Comment corriger les findings CSP de SecurityScorecard](/fr/blog/fix-securityscorecard-csp-findings)
* [Comment corriger les findings Content Security Policy de BitSight](/fr/blog/fix-bitsight-csp-findings)

## Comparaisons directes [#comparaisons-directes]

Plusieurs de ces headers ont un cousin proche avec lequel on les confond. Quand vous hésitez entre les deux, ces comparaisons détaillent le compromis :

* [X-Frame-Options contre frame-ancestors](/fr/blog/x-frame-options-vs-frame-ancestors) pour le contrôle du framing.
* [HSTS contre upgrade-insecure-requests](/fr/blog/hsts-vs-upgrade-insecure-requests) pour forcer HTTPS.
* [no-cache contre no-store](/fr/blog/no-cache-vs-no-store) pour garder les réponses sensibles hors des caches partagés.
* [SameSite contre les tokens CSRF](/fr/blog/samesite-vs-csrf-tokens) pour la défense contre les requêtes cross-site.

Pour la référence complète sur chaque header, voyez la [documentation des headers de sécurité](/fr/docs/web-security/security-headers).

## Voyez d'abord votre état actuel [#voyez-dabord-votre-état-actuel]

Avant de changer quoi que ce soit, scannez ce que le site en ligne envoie. Un scan liste les headers présents, ceux qui manquent et ceux qui portent des valeurs faibles : de quoi corriger en une seule passe, au lieu d'avancer à l'aveugle. Le [scanner de headers de sécurité](/tools/security-headers) vous donne cette liste, le [scanner CSP](/tools/csp-scanner) détaille la politique elle-même, et l'[évaluateur CSP](/tools/csp-evaluator) note un brouillon de politique avant que vous ne le déployiez. Une fois les headers en place, la [suite CSP](/platform/csp-builder) collecte les rapports de violation et suit la politique dans le temps pour que la note ne glisse pas discrètement après le prochain déploiement.

## Où cela vous mène [#où-cela-vous-mène]

Une note de headers de sécurité est une checklist, et la relever en est une aussi : envoyez `X-Content-Type-Options`, `Referrer-Policy`, `Strict-Transport-Security` et `Permissions-Policy` maintenant, puis construisez et appliquez une CSP stricte avec `frame-ancestors` pour la part la plus lourde du score. Scannez d'abord pour connaître votre point de départ, et continuez à scanner pour qu'un nouveau script tiers ne défasse pas le travail.

Pour collecter les rapports de violation, suivre votre politique dans le temps et surveiller les headers sur tout votre parc, [démarrez gratuitement avec CentralCSP](/register).

## Sources [#sources]

* [MDN, headers de sécurité et l'Observatory](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)
* [securityheaders.com](https://securityheaders.com/)

## Articles liés [#articles-liés]

* [Comment corriger les findings CSP de SecurityScorecard](/fr/blog/fix-securityscorecard-csp-findings)
* [Comment corriger les findings Content Security Policy de BitSight](/fr/blog/fix-bitsight-csp-findings)
* [Headers de sécurité hérités que vous pouvez retirer](/fr/blog/legacy-security-headers-to-retire)
* [Permissions-Policy expliqué](/fr/blog/permissions-policy-explained)