# 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 devez maintenant savoir quels headers poser et comment. La note est un score de checklist : un outil lit vos headers de réponse et marque chaque header recommandé présent ou manquant, puis pèse à quel point ceux qui sont présents sont bien configurés. Pour relever la note, vous envoyez le bon jeu de headers avec les bonnes valeurs. Voici ce jeu, ce que fait chaque header, et la valeur à déployer, avec les correctifs plus profonds liés depuis chaque étape.

Les différents scanners pondèrent les choses différemment. [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 ajoutent leur propre nommage 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 portent presque toute la note. Posez-les et configurez-les bien, et un A est 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 que la plupart des scanners pondèrent le plus haut, et une CSP stricte sans `'unsafe-inline'` est ce qui décroche la meilleure note sur un scanner conscient de 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 la devinez au jugé, alors 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` dit au navigateur de ne jamais joindre votre site autrement qu'en HTTPS, ce qui referme la faille où une première requête part 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 la façon dont certains uploads se transforment en scripts exécutables. Il a une seule valeur et aucun remplaçant moderne, alors 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. Pourquoi l'ancien header est en voie de disparition est traité 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. Un défaut raisonnable garde 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, car c'est celle qui a besoin du cycle report-only, collecter, appliquer pour éviter de casser le trafic réel. C'est aussi le facteur le plus lourd, donc elle mérite le 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é notent les mêmes headers mais publient leurs propres noms de findings, et le correctif est le même jeu de headers bien configuré. Si votre finding vient de l'une d'elles, les guides par agence relient 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 deux, celles-ci 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 quels headers sont présents, lesquels manquent, et lesquels portent des valeurs faibles, pour que vous corrigiez en une seule passe éclairée au lieu de deviner. Le [scanner de headers de sécurité](/tools/security-headers) vous donne cette liste, le [scanner CSP](/tools/csp-scanner) rend compte de la politique en particulier, et l'[évaluateur CSP](/tools/csp-evaluator) note une politique brouillon avant que vous la 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, donc la relever est aussi une checklist : 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)