Les mots-clés sources CSP, self, unsafe-inline et plus

Référence des sources mot-clé CSP, self, none, unsafe-inline, unsafe-eval, strict-dynamic, unsafe-hashes, report-sample, et ce que chacune autorise.

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 :

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

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.

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é

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.
`'unsafe-eval'`	❌ Risqué	`eval()`, `new Function()` et `setTimeout`/`setInterval` appelés avec une chaîne. Voir unsafe-eval.
`'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'`	🧪 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`, sans définition fonctionnelle et sans prise en charge navigateur.

Deux règles qui changent l'interaction 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.

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 pour le schéma complet.

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

'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. 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' 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 sans définition fonctionnelle ; ni l'un ni l'autre n'a sa place dans une vraie politique.

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, 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

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.

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 prend sa propre paire de mots-clés, 'allow' et 'block', qui ne sont valables nulle part ailleurs.

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

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

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 :

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

Recommandation

Construisez la confiance des scripts sur un nonce ou un hash 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 :

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

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 et le guide de CSP stricte de web.dev : 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

'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

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 ?

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é.

Mots-clés