# Mots-clés (/fr/docs/web-security/policies/content-security-policy/values/csp-keywords)



Les sources mot-clé sont les jetons entre apostrophes que vous placez dans une
liste de sources d'une politique de sécurité du contenu (CSP), comme `'self'`,
`'none'`, `'unsafe-inline'` et `'strict-dynamic'`. Chacun active un comportement
précis plutôt que de désigner une URL, et ils décident donc comment le navigateur
traite le code inline, le script dynamique et votre propre origine. Les
apostrophes font partie du jeton : si vous les retirez, le navigateur lit le mot
comme un nom d'hôte.

Un usage sûr, des mots-clés portant une politique de script stricte :

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

## Syntaxe [#syntaxe]

Une source mot-clé est un jeton fixe entouré d'apostrophes, listé aux côtés des
éventuelles sources d'hôte, de schéma, de nonce ou de hash dans la valeur d'une
directive.

```http
Content-Security-Policy:
    script-src 'self' 'strict-dynamic' 'nonce-r4nd0m';
    object-src 'none';
    base-uri 'none'
```

Les noms de mots-clés sont insensibles à la casse, mais les apostrophes sont
obligatoires. La plupart des mots-clés n'ont de sens que dans les directives qui
chargent du script ou du style ; `'self'` et `'none'` fonctionnent dans n'importe
quelle directive à liste de sources.

## Ce que fait chaque mot-clé [#ce-que-fait-chaque-mot-clé]

| Mot-clé                                                                                                                                       | Statut          | Ce qu'il autorise                                                                                                                                                                                                        |
| --------------------------------------------------------------------------------------------------------------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `'self'`                                                                                                                                      | ✅ Bon           | L'origine de la page elle-même, le schéma, l'hôte et le port exacts. N'inclut pas les sous-domaines et n'autorise pas le code inline.                                                                                    |
| `'none'`                                                                                                                                      | ✅ Bon           | Rien. Utilisé seul pour bloquer toute source d'une directive.                                                                                                                                                            |
| `'strict-dynamic'`                                                                                                                            | ✅ Bon           | La propagation de la confiance d'un script autorisé par nonce ou hash vers les scripts qu'il charge. Désactive les allowlists d'hôte et de schéma.                                                                       |
| `'wasm-unsafe-eval'`                                                                                                                          | ✅ Bon           | La compilation et l'instanciation WebAssembly uniquement, pas le `eval()` JavaScript. Largement pris en charge par les navigateurs actuels.                                                                              |
| `'report-sample'`                                                                                                                             | ✅ Bon           | Un court échantillon (les 40 premiers caractères) du contenu bloqué dans le rapport de violation. Aide au reporting uniquement.                                                                                          |
| `'trusted-types-eval'`                                                                                                                        | ✅ Bon           | `eval()` uniquement lorsqu'il reçoit un `TrustedScript` et que les Trusted Types sont appliqués. Nouveau ; récemment devenu disponible sur les versions actuelles de Chrome, Firefox et Safari.                          |
| `'unsafe-inline'`                                                                                                                             | ❌ Risqué        | Les blocs `<script>` et `<style>` inline, les URL `javascript:` et les event handlers inline. Annule la principale protection contre le [XSS](/fr/blog/unsafe-inline-csp).                                               |
| `'unsafe-eval'`                                                                                                                               | ❌ Risqué        | `eval()`, `new Function()` et `setTimeout`/`setInterval` appelés avec une chaîne. Voir [unsafe-eval](/fr/blog/unsafe-eval-csp).                                                                                          |
| `'unsafe-hashes'`                                                                                                                             | ❌ Risqué        | Les sources de hash pour correspondre aux event handlers inline et aux attributs `style=`. Cross-browser, mais rouvre les surfaces des event handlers.                                                                   |
| `'inline-speculation-rules'`                                                                                                                  | 🧪 Expérimental | Les blocs `<script type="speculationrules">` inline. Porté par Chromium ; absent de la grammaire CSP.                                                                                                                    |
| [`'report-sha256'` / `'report-sha384'` / `'report-sha512'`](/fr/docs/web-security/policies/content-security-policy/values/report-sha-keyword) | 🧪 Expérimental | La collecte report-only de hashs de script via des rapports `csp-hash`. Chromium uniquement.                                                                                                                             |
| `'unsafe-webtransport-hashes'`                                                                                                                | 🧪 Expérimental | Les connexions WebTransport validées par hash de certificat. Dans la grammaire de la spec ; aucune prise en charge navigateur documentée.                                                                                |
| `'unsafe-allow-redirects'`                                                                                                                    | ⚠️ Déprécié     | Rien en pratique. Un vestige de la directive supprimée [`navigate-to`](/fr/docs/web-security/policies/content-security-policy/directives/navigate-to), sans définition fonctionnelle et sans prise en charge navigateur. |

## Deux règles qui changent l'interaction des mots-clés [#deux-règles-qui-changent-linteraction-des-mots-clés]

Deux interactions prennent les gens au dépourvu, parce qu'ajouter un mot-clé en
désactive silencieusement un autre.

Un nonce ou un hash fait ignorer `'unsafe-inline'`. Lorsqu'une valeur `script-src`
ou `style-src` contient une source de nonce ou de hash, le navigateur écarte
`'unsafe-inline'` de cette directive. Donc une fois que vous ajoutez un nonce ou un
hash, retirez `'unsafe-inline'` : il n'a aucun effet, et le laisser ne fait que
rendre la politique plus difficile à lire. Ne comptez pas sur `'unsafe-inline'`
comme actif lorsqu'un nonce est présent.

```http
Content-Security-Policy: script-src 'unsafe-inline' 'nonce-r4nd0m'
```

Dans cette politique, seuls les scripts portant `nonce="r4nd0m"` s'exécutent ;
`'unsafe-inline'` n'a aucun effet.

`'strict-dynamic'` ignore les allowlists d'hôte et de schéma. Lorsque
`'strict-dynamic'` est présent dans `script-src`, le navigateur ignore chaque
entrée de source d'hôte et de source de schéma (et `'unsafe-inline'`) de cette
directive. Seuls s'exécutent les scripts autorisés par nonce ou hash, plus tous
les scripts qu'ils créent à l'exécution. C'est ce qui permet à une politique
stricte d'éviter de maintenir une allowlist d'hôtes. Voir
[strict-dynamic](/fr/blog/strict-dynamic-csp) pour le schéma complet.

```http
Content-Security-Policy:
    script-src 'strict-dynamic' 'nonce-r4nd0m' https://cdn.example.com
```

Ici, `https://cdn.example.com` est ignoré. Le script du CDN ne se charge que si le
script d'amorçage autorisé par nonce l'injecte.

## Les mots-clés les plus récents [#les-mots-clés-les-plus-récents]

`'trusted-types-eval'` est le dernier ajout au jeu de mots-clés. Il n'autorise
`eval()` et ses variantes que lorsque l'argument est un `TrustedScript`, et
seulement tant que les Trusted Types sont appliqués avec
[require-trusted-types-for](/fr/docs/web-security/policies/content-security-policy/directives/require-trusted-types-for).
Utilisez-le à la place de `'unsafe-eval'` quand une dépendance a réellement besoin
d'eval : la chaîne doit toujours passer par une politique Trusted Types que vous
avez écrite, donc un texte injecté ne peut pas atteindre l'interpréteur. Il est
récemment devenu disponible sur les versions actuelles de Chrome, Firefox et
Safari ; considérez-le donc comme sûr mais très récent.

Les mots-clés de hash report-only
[`'report-sha256'`, `'report-sha384'` et `'report-sha512'`](/fr/docs/web-security/policies/content-security-policy/values/report-sha-keyword)
n'autorisent ni ne bloquent jamais rien ; ils demandent au navigateur de signaler
un hash de chaque script qu'il exécute. Ils figurent dans la grammaire du
brouillon d'éditeur CSP3 et sont stables dans Chromium, sans prise en charge
Firefox ou Safari pour le moment.

`'inline-speculation-rules'` autorise les blocs
`<script type="speculationrules">` inline et rien d'autre. C'est une extension
portée par Chromium qui ne fait pas partie de la grammaire CSP (Safari la propose
derrière un flag), donc ne comptez dessus que pour les utilisateurs Chromium.
`'unsafe-webtransport-hashes'` figure dans la grammaire de la spec sans prise en
charge navigateur documentée, et `'unsafe-allow-redirects'` est un vestige de la
directive supprimée
[`navigate-to`](/fr/docs/web-security/policies/content-security-policy/directives/navigate-to)
sans définition fonctionnelle ; ni l'un ni l'autre n'a sa place dans une vraie
politique.

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

`'unsafe-inline'` et `'unsafe-eval'` sont les deux valeurs qui désactivent la
protection pour laquelle CSP existe. Un attaquant qui injecte du balisage dans
votre page peut exécuter du script inline dès l'instant où `'unsafe-inline'` est
dans `script-src`, ce qui est exactement l'attaque qu'une politique est censée
bloquer. Remplacez `'unsafe-inline'` par un
[nonce ou un hash](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce),
et remplacez `'unsafe-eval'` en supprimant les appels de type `eval` ou en les
plaçant derrière Trusted Types avec `'trusted-types-eval'`. Traitez
`'unsafe-hashes'` comme un dernier recours pour les anciens handlers inline : il
est standard et cross-browser, mais il rouvre la surface d'attaque des event
handlers qu'une politique est censée fermer, donc cantonnez-le aux hashs précis
dont vous avez besoin.

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

Les mots-clés sont la façon dont une politique exprime la différence entre faire
confiance à une origine et faire confiance à du code inline arbitraire. Utiliser
`'self'` avec un nonce et `'strict-dynamic'` au lieu de `'unsafe-inline'` bloque
les blocs `<script>` injectés et les handlers inline, ce qui est la défense
centrale contre le cross-site scripting (XSS). Vous pouvez auditer la façon dont
une politique utilise ces mots-clés avec l'[évaluateur CSP](/tools/csp-evaluator).

## Limites connues [#limites-connues]

Les règles « le nonce supprime `'unsafe-inline'` » et « `'strict-dynamic'` ignore
les allowlists » s'appliquent à `script-src` (et, pour `'unsafe-inline'`, à
`style-src`) ; elles ne changent pas le comportement dans les directives qui n'ont
jamais accepté de code inline. `'report-sample'` ajoute seulement un échantillon
aux rapports et n'influe jamais sur le fait qu'un contenu soit bloqué.
`'inline-speculation-rules'` et les mots-clés `'report-sha...'` sont en pratique
propres à Chromium, donc ne comptez pas sur eux pour le comportement dans Firefox
ou Safari. La
[directive webrtc](/fr/docs/web-security/policies/content-security-policy/directives/webrtc)
prend sa propre paire de mots-clés, `'allow'` et `'block'`, qui ne sont valables
nulle part ailleurs.

## Risques [#risques]

Laisser `'unsafe-inline'` ou `'unsafe-eval'` dans un `script-src` de production est
la façon la plus courante pour une CSP de finir par offrir peu de protection. Le
risque inverse consiste à ajouter un nonce ou `'strict-dynamic'` en oubliant qu'il
désactive l'allowlist d'hôtes sur laquelle vous comptiez, ce qui peut casser des
scripts légitimes jusqu'à ce que vous les marquiez avec le nonce ou laissiez
`'strict-dynamic'` leur propager la confiance.

## Exemples [#exemples]

Une politique stricte qui fait confiance au script inline par nonce et laisse ce
script charger le reste :

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

Une politique de style qui autorise deux styles inline précis par hash et bloque
le reste :

```http
Content-Security-Policy: style-src 'self' 'sha256-abc123...' 'sha256-def456...'
```

## Recommandation [#recommandation]

Construisez la confiance des scripts sur un
[nonce ou un hash](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce)
plus `'strict-dynamic'`, et gardez les mots-clés `unsafe-*` hors de la politique.
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 le schéma de CSP stricte que recommandent 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) :
chaque script est approuvé individuellement par nonce ou hash, `'strict-dynamic'`
les laisse charger ce dont ils ont besoin, et aucun `'unsafe-inline'` ni
`'unsafe-eval'` ne rouvre les chemins d'injection que la politique existe pour
fermer.

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

`'self'`, `'none'`, `'unsafe-inline'`, `'unsafe-eval'`, `'strict-dynamic'`,
`'unsafe-hashes'`, `'report-sample'` et `'wasm-unsafe-eval'` sont pris en charge
par les navigateurs actuels. `'trusted-types-eval'` est cross-browser mais très
récent, venant tout juste de devenir disponible sur les versions actuelles de
Chrome, Firefox et Safari. `'inline-speculation-rules'` et les
mots-clés `'report-sha...'` ne fonctionnent que dans Chromium, et
`'unsafe-webtransport-hashes'` et `'unsafe-allow-redirects'` n'ont aucune prise
en charge navigateur.

## FAQ [#faq]

### Que fait strict-dynamic ? [#que-fait-strict-dynamic-]

`'strict-dynamic'` laisse la confiance se propager d'un script autorisé par nonce
ou hash vers les scripts qu'il crée à l'exécution. Quand il est présent dans
`script-src`, le navigateur ignore chaque entrée host-source et scheme-source (et
`'unsafe-inline'`) de cette directive, si bien qu'une politique stricte évite de
maintenir une allowlist d'hôtes.

### unsafe-inline est-il sûr si j'utilise aussi un nonce ? [#unsafe-inline-est-il-sûr-si-jutilise-aussi-un-nonce-]

Quand une valeur `script-src` ou `style-src` contient une source nonce ou hash, le
navigateur ignore `'unsafe-inline'` dans cette directive, il est donc inoffensif
mais inutile : seuls les scripts correspondant au nonce s'exécutent. Le laisser
n'ajoute rien d'autre que de l'encombrement, retirez-le donc une fois le nonce ou
le hash ajouté.

## Voir aussi [#voir-aussi]

* [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)
* [Source hôte](/fr/docs/web-security/policies/content-security-policy/values/csp-host-source)
* [Hashs et nonces](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce)
* [Mot-clé report-sha256](/fr/docs/web-security/policies/content-security-policy/values/report-sha-keyword)
* [Comment retirer unsafe-inline](/fr/blog/unsafe-inline-csp)
* [Remplacer unsafe-eval](/fr/blog/unsafe-eval-csp)
* [Construire une politique stricte avec strict-dynamic](/fr/blog/strict-dynamic-csp)

## Sources [#sources]

* [W3C, Content Security Policy Level 3, source lists](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)