# Hashs et nonces (/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce)



Les sources nonce et hash permettent à une politique de sécurité du contenu (CSP)
d'autoriser un script ou un style inline précis sans activer
[`'unsafe-inline'`](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords).
Un nonce est un jeton à usage unique partagé entre la politique et l'élément ; un
hash est une empreinte du contenu exact de l'élément. Tous deux disent « fais
confiance à ce code inline précis et à rien d'autre », ce qui est le fondement
d'une CSP stricte.

Une politique à nonce et la balise script qui lui correspond :

```http
Content-Security-Policy: script-src 'nonce-{RANDOM}'
```

```html
<script nonce="{RANDOM}">init();</script>
```

## Syntaxe [#syntaxe]

Une source de nonce est `'nonce-'` suivi d'une valeur base64. Une source de hash
est une étiquette d'algorithme, `sha256`, `sha384` ou `sha512`, un tiret, puis
l'empreinte base64.

```http
Content-Security-Policy: script-src 'nonce-r4nd0m' 'sha256-RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc='
```

L'élément correspondant référence le même nonce, ou a simplement un contenu dont
l'empreinte est égale au hash.

```html
<script nonce="r4nd0m">doSomething();</script>
```

| Valeur                                           | Statut   | Description                                                                                                       |
| ------------------------------------------------ | -------- | ----------------------------------------------------------------------------------------------------------------- |
| Source de nonce `'nonce-<base64>'`               | ✅ Bon    | Un jeton neuf et impossible à deviner, propre à chaque réponse, correspondant à l'attribut `nonce` de l'élément.  |
| Source de hash pour du contenu inline            | ✅ Bon    | Une empreinte `sha256`, `sha384` ou `sha512` du texte exact du script ou du style inline.                         |
| Source de hash pour des scripts externes         | ✅ Bon    | Correspond à l'empreinte d'intégrité de type SRI du script. Largement pris en charge par les navigateurs actuels. |
| Hash pour event handlers, avec `'unsafe-hashes'` | ❌ Risqué | Étend la correspondance des hashs aux handlers inline et aux attributs `style=`, rouvrant cette surface.          |

Lorsqu'un nonce ou un hash est présent dans une directive,
[`'unsafe-inline'`](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords)
dans cette même directive est ignoré. Une fois un nonce ou un hash ajouté, retirez
`'unsafe-inline'` : le navigateur l'ignore déjà, donc il ne fait qu'encombrer la
politique.

## Règles des nonces [#règles-des-nonces]

Un nonce ne vous protège que si un attaquant ne peut ni le prédire ni le réutiliser.
Suivez toutes ces règles.

* Générez-le côté serveur, à neuf pour chaque réponse. Un nonce statique figé dans
  un template équivaut à `'unsafe-inline'`, car un script injecté peut recopier la
  valeur connue.
* Utilisez un générateur aléatoire cryptographiquement sûr (CSPRNG) avec au moins
  128 bits d'entropie, encodé en base64.
* Rendez-le unique par réponse. Ne mettez jamais en cache une page avec son nonce,
  et n'en réutilisez jamais un entre requêtes.
* Placez la même valeur dans la politique et dans l'attribut `nonce` de l'élément.
  La moindre différence bloque le script.

```http
Content-Security-Policy: script-src 'nonce-8IBTHwOdqNKAWeKl7plt8g=='
```

```html
<script nonce="8IBTHwOdqNKAWeKl7plt8g==">init();</script>
```

Voir [mettre en place un nonce CSP](/fr/blog/csp-nonce-setup) pour un guide par
framework.

## Règles des hashs [#règles-des-hashs]

Une source de hash correspond à un élément inline dont le contenu produit
l'empreinte donnée. Elle ne demande aucun jeton par réponse, ce qui en fait un bon
choix pour du code inline statique.

* L'empreinte est calculée sur le contenu texte exact du `<script>` ou du
  `<style>` inline : les octets UTF-8 entre les balises, chaque espace, retour à
  la ligne et caractère compté, sans les balises elles-mêmes. Un seul changement
  d'espace invalide le hash.
* Utilisez `sha256`, `sha384` ou `sha512`. L'algorithme de la source doit
  correspondre à celui que vous avez calculé.
* Pour correspondre à un event handler inline (comme `onclick=`) ou à un attribut
  `style=`, il faut aussi
  [`'unsafe-hashes'`](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords)
  dans la directive. Sans lui, les hashs ne correspondent qu'aux blocs `<script>`
  et `<style>` complets.
* La correspondance d'un script externe avec son empreinte d'intégrité de type SRI
  est définie dans CSP3 et fonctionne dans les navigateurs actuels. Un hash CSP n'est pas la
  même chose qu'un hash Subresource Integrity ; voir
  [SRI vs hash CSP](/fr/blog/sri-vs-csp-hash) pour la distinction.

### Calculer un hash [#calculer-un-hash]

Le hash est l'empreinte base64 du contenu inline exact, sans les balises et sans
retour à la ligne final, écrite dans la politique sous la forme
`'sha256-<sortie>'`. Collez le snippet dans le
[générateur de hash](/tools/csp-hash) et il renvoie la source prête à
l'emploi. Voir
[calculer un hash sha256 CSP](/fr/blog/csp-hash-sha256) pour des exemples
détaillés.

## Valeurs non sûres à éviter [#valeurs-non-sûres-à-éviter]

Ce qui ruine un nonce, c'est la réutilisation : un nonce prévisible, statique ou
mis en cache permet à un script injecté de présenter la valeur connue et de
s'exécuter. Pour les hashs, le piège est un `'unsafe-hashes'` appliqué trop
largement, puisqu'il étend la correspondance aux attributs ; cantonnez-le aux
hashs exacts dont vous avez besoin. Ne retombez jamais sur `'unsafe-inline'` pour
« faire marcher le nonce » : il est ignoré quand un nonce est présent et ne fait
que brouiller la politique.

## Contre quoi cela protège [#contre-quoi-cela-protège]

C'est par les nonces et les hashs qu'une politique distingue les quelques scripts
inline que vous avez écrits de ceux qu'un attaquant injecte, et c'est ce qui ferme
le vecteur XSS principal que `'unsafe-inline'` laisse ouvert. Pour vérifier qu'une
politique s'appuie réellement dessus, passez-la dans
l'[évaluateur CSP](/tools/csp-evaluator).

## Contournements et limites connus [#contournements-et-limites-connus]

En pratique, le contournement, c'est un nonce divulgué ou devinable : l'entropie
et l'unicité par réponse ne sont donc pas facultatives. Les hashs sont fragiles face aux
changements de contenu : une étape de build qui reformate ou minifie le code
inline invalide le hash stocké et casse le script jusqu'à ce que vous le
recalculiez.

## Risques [#risques]

Le risque opérationnel courant est un déploiement qui met en cache une page avec
son nonce, figeant un même nonce pour de nombreux utilisateurs, ce qui casse des
scripts légitimes (quand le cache et le header divergent) et affaiblit la
protection. L'équivalent côté hash est de livrer un changement de code sans mettre
à jour le hash. Déployez les changements en
[mode Report-Only](/fr/docs/web-security/policies/content-security-policy/report-only)
pour attraper les deux avant qu'ils n'atteignent les utilisateurs.

## Recommandation [#recommandation]

Utilisez un nonce quand la page est rendue à chaque requête et que vous pouvez
injecter une valeur neuve à la fois dans le header et dans le balisage ; il gère
proprement le code inline dynamique. Utilisez un hash quand le contenu inline est
statique et que vous préférez ne pas faire circuler un nonce à travers des couches
de cache, ou quand vous ne pouvez pas définir de header au moment de la requête
(un hash fonctionne dans une politique `<meta>`). Dans les deux cas, associez-le à
[`'strict-dynamic'`](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords)
pour que le script d'amorçage de confiance puisse charger le reste. Définissez
explicitement les directives restantes pour que rien ne se rabatte implicitement :

```http
Content-Security-Policy:
    default-src 'self';
    script-src 'nonce-{RANDOM}' 'strict-dynamic';
    style-src 'self';
    img-src 'self';
    font-src 'self';
    connect-src 'self';
    media-src 'self';
    manifest-src 'self';
    frame-src 'none';
    worker-src 'self';
    object-src 'none';
    base-uri 'none';
    form-action 'self';
    frame-ancestors 'none';
    upgrade-insecure-requests;
    report-to csp-endpoint
```

```http
Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
```

C'est la CSP stricte que la
[cheat sheet CSP de l'OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html)
et le [guide de CSP stricte de web.dev](https://web.dev/articles/strict-csp)
recommandent plutôt que les allowlists d'hôtes : seuls les scripts que vous avez
marqués s'exécutent, et aucun `'unsafe-inline'` n'affaiblit la politique.

## Exemples [#exemples]

Une politique de script stricte utilisant un nonce et `'strict-dynamic'` :

```http
Content-Security-Policy:
    script-src 'nonce-8IBTHwOdqNKAWeKl7plt8g==' 'strict-dynamic';
    object-src 'none';
    base-uri 'none'
```

Autoriser un script inline statique par hash :

```http
Content-Security-Policy: script-src 'self' 'sha256-RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc='
```

## Prise en charge par les navigateurs [#prise-en-charge-par-les-navigateurs]

Les sources de nonce et les sources de hash `sha256`/`sha384`/`sha512` font partie
du cœur de CSP et sont largement prises en charge par les navigateurs actuels.
L'extension `'unsafe-hashes'` pour les attributs est également largement prise en
charge. Il en va de même pour la correspondance de hash sur les scripts externes,
que les navigateurs actuels acceptent désormais.

## FAQ [#faq]

### Faut-il utiliser un nonce ou un hash ? [#faut-il-utiliser-un-nonce-ou-un-hash-]

Utilisez un nonce quand la page est rendue à chaque requête et que vous pouvez
injecter une valeur neuve à la fois dans le header et dans le balisage ; il gère
proprement le code inline dynamique. Utilisez un hash quand le contenu inline est
statique ou que vous ne pouvez pas définir de header au moment de la requête,
puisqu'un hash fonctionne dans une politique `<meta>`.

### Comment générer un hash CSP ? [#comment-générer-un-hash-csp-]

Calculez l'empreinte base64 du contenu inline exact, sans les balises et sans
retour à la ligne final, puis écrivez-la dans la politique sous la forme
`'sha256-<sortie>'`. Un seul changement d'espace invalide le hash. Collez le
snippet dans le [générateur de hash](/tools/csp-hash) et il renvoie la
source prête à l'emploi.

## Voir aussi [#voir-aussi]

* [Mots-clés](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords)
* [Source hôte](/fr/docs/web-security/policies/content-security-policy/values/csp-host-source)
* [Directive script-src](/fr/docs/web-security/policies/content-security-policy/directives/script-src)
* [Directive style-src](/fr/docs/web-security/policies/content-security-policy/directives/style-src)
* [Mettre en place un nonce CSP](/fr/blog/csp-nonce-setup)
* [Calculer un hash sha256 CSP](/fr/blog/csp-hash-sha256)
* [Outil générateur de hash](/tools/csp-hash)

## Sources [#sources]

* [W3C, Content Security Policy Level 3, nonce and hash sources](https://w3c.github.io/webappsec-csp/#framework-directive-source-list)
* [MDN, CSP source values](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy)
* [web.dev, Mitigate XSS with a strict CSP](https://web.dev/articles/strict-csp)
* [OWASP, Content Security Policy cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html)