En-tête Content-Security-Policy (CSP)

Syntaxe

Content-Security-Policy: <policy-directive>; <policy-directive>

où <policy-directive> se compose de : <directive> <value> sans ponctuation interne.

Directives

Directives de récupération (fetch)

Les directives de récupération contrôlent les emplacements à partir desquels certains types de ressources peuvent être chargés.

child-src

Définit les sources valides pour les web workers et les contextes de navigation imbriqués chargés avec des éléments HTML tels que <frame> et <iframe>.

Repli pour frame-src et worker-src.

connect-src

Restreint les URL qui peuvent être chargées par les interfaces de script.

default-src

Sert de repli pour les autres directives de récupération.

Repli pour toutes les autres directives de récupération.

fenced-frame-src

Définit les sources valides pour les contextes de navigation imbriqués chargés dans des éléments HTML <fencedframe>.

font-src

Définit les sources valides pour les polices chargées avec @font-face.

frame-src

Définit les sources valides pour les contextes de navigation imbriqués chargés dans des éléments HTML tels que <frame> et <iframe>.

img-src

Définit les sources valides pour les images et les favicons.

manifest-src

Définit les sources valides pour les fichiers de manifeste d'application.

media-src

Définit les sources valides pour le chargement des médias avec les éléments HTML <audio>, <video> et <track>.

object-src

Définit les sources valides pour les éléments HTML <object> et <embed>.

prefetch-src

Définit les sources valides à précharger ou à pré-rendre.

script-src

Définit les sources valides pour les ressources JavaScript et WebAssembly.

Repli pour script-src-elem et script-src-attr.

script-src-elem

Définit les sources valides pour les éléments HTML JavaScript <script>.

script-src-attr

Définit les sources valides pour les gestionnaires d'évènements JavaScript embarqué.

style-src

Définit les sources valides pour les feuilles de styles.

Repli pour style-src-elem et style-src-attr.

style-src-elem

Définit les sources valides pour les éléments HTML <style> et les éléments HTML <link> ayant rel="stylesheet".

style-src-attr

Définit les sources valides pour les styles embarqués appliqués à des éléments individuels du DOM.

worker-src

Définit les sources valides pour les scripts Worker, SharedWorker ou ServiceWorker.

Toutes les directives de récupération peuvent être définies avec la valeur unique 'none', indiquant que le type de ressource concerné doit être complètement bloqué, ou avec une ou plusieurs valeurs d'expression de source, indiquant les sources valides pour ce type de ressource. Voir Syntaxe des directives de récupération pour plus de détails.

Replis

Certaines directives de récupération servent de replis pour d'autres directives plus spécifiques. Cela signifie que si la directive plus spécifique n'est pas définie, alors le repli est utilisé pour définir une règle pour ce type de ressource.

• default-src est un repli pour toutes les autres directives de récupération.
• script-src est un repli pour script-src-attr et script-src-elem.
• style-src est un repli pour style-src-attr et style-src-elem.
• child-src est un repli pour frame-src et worker-src.

Par exemple :

• Si img-src est omise mais que default-src est incluse, alors la règle définie par default-src est appliquée aux images.
• Si script-src-elem est omise mais que script-src est incluse, alors la règle définie par script-src est appliquée aux éléments <script>.
• Si script-src-elem et script-src sont toutes deux omises, mais que default-src est incluse, alors la règle définie par default-src est appliquée aux éléments <script>.

Directives de document

Les directives de document permettent de paramétrer les propriétés d'un document ou d'un environnement worker auquel une règle s'applique.

base-uri

Restreint les URL qui peuvent être utilisées dans l'élément <base> d'un document.

sandbox

Active un bac-à-sable pour la ressource demandée, de façon analogue à l'attribut sandbox de <iframe>.

Directives de navigation

Les directives de navigation permettent de paramétrer les emplacements vers lesquels l'utilisateur peut naviguer ou envoyer un formulaire, par exemple.

form-action

Restreint les URL qui peuvent être utilisées comme cibles pour envoyer des formulaires depuis un contexte donné.

frame-ancestors

Définit les parents valides qui peuvent intégrer une page grâce aux éléments <frame>, <iframe>, <object>, ou <embed>.

Directives de rapport

Les directives de rapport contrôlent l'URL de destination pour les rapports d'enfreinte CSP dans Content-Security-Policy et Content-Security-Policy-Report-Only.

report-to

Fournit au navigateur un jeton identifiant le point de terminaison de rapport ou le groupe de points de terminaison auquel envoyer les informations d'enfreinte CSP. Les points de terminaison représentés par le jeton sont fournis par d'autres en-têtes HTTP, tels que Reporting-Endpoints et Report-To .

Attention : Cette directive est destinée à remplacer report-uri ; dans les navigateurs qui prennent en charge report-to, la directive report-uri est ignorée. Cependant, tant que report-to n'est pas largement supportée, il est recommandé de définir les deux en-têtes comme illustré (où nom_point_de_terminaison est le nom d'un point de terminaison fourni séparément) :

http

Content-Security-Policy: …; report-uri https://endpoint.exemple.com; report-to nom_point_de_terminaison

Autres directives

require-trusted-types-for

Implique l'utilisation de Types de confiance sur les puits d'injection XSS du DOM.

trusted-types

Utilisée pour définir une liste blanche de règles de types de confiance. Les types de confiance permettent aux applications de verrouiller les puits d'injection XSS du DOM pour n'accepter que des valeurs typées et non falsifiables à la place des chaînes de caractères.

upgrade-insecure-requests

Indique à l'agent utilisateur de traiter toutes les URL non-sécurisées d'un site (celles servies par HTTP) comme si elles avaient été remplacées par des URL sécurisées (celles servies par HTTPS). Cette directive est destinée aux sites web qui possèdent un grand nombre d'URL historiques non-sécurisées devant être réécrites.

Directives obsolètes

block-all-mixed-content

Empêche le chargement de toute ressource par HTTP lorsque la page est chargée avec HTTPS.

report-uri

Fournit au navigateur une URL où les rapports d'enfreinte CSP doivent être envoyés. Cette directive est remplacée par la directive report-to.

Syntaxe des directives de récupération

Toutes les directives de récupération peuvent être définies de l'une des façons suivantes :

• la valeur unique 'none', indiquant que le type de ressource concerné doit être complètement bloqué
• une ou plusieurs valeurs d'expression de source, indiquant les sources valides pour ce type de ressource.

Chaque expression de source prend l'une des formes listées ci-dessous. Notez que toutes les formes ne sont pas applicables à toutes les directives de récupération : consultez la documentation de chaque directive pour savoir quelles formes lui sont applicables.

Les formats <host-source> et <scheme-source> doivent être non entourés de guillemets, et tous les autres formats doivent être entourés de guillemets simples.

nonce-<nonce_value>

Cette valeur consiste en la chaîne de caractères nonce- suivie d'une valeur de nombre unique. La valeur du nonce peut utiliser n'importe quel caractère de la Base64 ou de la Base64 sûre pour les URL.

Cette chaîne de caractères est une valeur aléatoire que le serveur génère pour chaque réponse HTTP. Par exemple :

'nonce-416d1177-4d12-4e3b-b7c9-f6c409789fb8'

Le serveur peut alors inclure cette même valeur comme valeur de l'attribut nonce de toute ressource <script> ou <style> qu'il souhaite charger depuis le document.

Le navigateur compare la valeur de la directive CSP avec la valeur de l'attribut de l'élément, et ne charge la ressource que si elles correspondent.

Si une directive contient un nombre unique et unsafe-inline, alors le navigateur ignore unsafe-inline.

Voir la section Nombres uniques du guide CSP pour plus d'informations d'utilisation.

<hash_algorithm>-<hash_value>

Cette valeur consiste en une chaîne de caractères identifiant un algorithme de hachage, suivie de -, puis d'une valeur de hachage. La valeur de hachage peut utiliser n'importe quel caractère de la Base64 ou de la Base64 sûre pour les URL.

• L'identifiant de l'algorithme de hachage doit être l'un des suivants entre sha256, sha384 ou sha512.
• La valeur de hachage est le résultat en base64 de la fonction de hachage d'une ressource <script> ou <style>, calculée à l'aide de l'une des fonctions de hachage suivantes : SHA-256, SHA-384 ou SHA-512.

Par exemple :

'sha256-cd9827ad...'

Lorsque le navigateur reçoit le document, il effectue le hachage du contenu de chaque élément <script> et <style>, compare le résultat avec les hachages présents dans la directive CSP, et ne charge la ressource que s'il y a correspondance.

Si l'élément charge une ressource externe (par exemple, avec l'attribut src), alors l'élément doit également avoir l'attribut integrity renseigné.

Si une directive contient une valeur de hachage et unsafe-inline, alors le navigateur ignore unsafe-inline.

Voir la section Hachages du guide CSP pour plus d'informations d'utilisation.

<host-source>

Une URL ou adresse IP d'un hôte qui est une source valide pour la ressource.

Le schéma, le numéro de port et le chemin sont optionnels.

Si le schéma est omis, celui de l'origine du document est utilisé.

Lors de la comparaison des schémas, les mises à niveau sécurisées sont autorisées. Par exemple :

• http://exemple.com autorise également les ressources provenant de https://exemple.com
• ws://exemple.org autorise également les ressources provenant de wss://exemple.org.

Les jokers ('*') peuvent être utilisés pour les sous-domaines, l'adresse de l'hôte et le numéro de port, indiquant que toutes les valeurs légales de chacun sont valides. Par exemple :

• http://*.exemple.com autorise les ressources provenant de n'importe quel sous-domaine de exemple.com, en HTTP ou HTTPS.

Les chemins qui se terminent par / correspondent à tout chemin dont ils sont le préfixe. Par exemple :

• exemple.com/api/ autorise les ressources provenant de exemple.com/api/users/new.

Les chemins qui ne se terminent pas par / sont comparés exactement. Par exemple :

• https://exemple.com/file.js autorise les ressources provenant de https://exemple.com/file.js mais pas de https://exemple.com/file.js/file2.js.

<scheme-source>

Un schéma, tel que https:. Les deux-points sont obligatoires.

Les mises à niveau sécurisées sont autorisées, donc :

• http: autorise également les ressources chargées en HTTPS
• ws: autorise également les ressources chargées en WSS.

self

Les ressources du type donné ne peuvent être chargées que depuis la même origine que le document.

Les mises à niveau sécurisées sont autorisées. Par exemple :

• Si le document est servi depuis http://exemple.com, alors une CSP avec 'self' autorise également les ressources provenant de https://exemple.com.
• Si le document est servi depuis ws://exemple.org, alors une CSP avec 'self' autorise également les ressources provenant de wss://exemple.org.

trusted-types-eval

Par défaut, si une CSP contient une directive default-src ou script-src, alors les fonctions JavaScript qui évaluent leurs arguments comme du JavaScript sont désactivées. Cela inclut eval(), l'argument code de setTimeout(), ou le constructeur Function().

Le mot-clé trusted-types-eval peut être utilisé pour annuler cette protection, mais uniquement lorsque les Types de confiance sont appliqués et transmis à ces fonctions à la place de chaînes de caractères. Cela permet l'évaluation dynamique de chaînes de caractères comme JavaScript, mais seulement après que les entrées ont été transmises à une fonction de transformation avant injection, ce qui permet de nettoyer l'entrée pour supprimer tout balisage potentiellement dangereux.

Le mot-clé trusted-types-eval doit être utilisé à la place de 'unsafe-eval' lors de l'utilisation de ces méthodes avec des types de confiance. Cela garantit que l'accès à ces méthodes est bloqué sur les navigateurs qui ne prennent pas en charge les types de confiance.

Voir la section eval() et API similaires du guide CSP pour plus d'informations d'utilisation.

unsafe-eval

Par défaut, si une CSP contient une directive default-src ou script-src, alors les fonctions JavaScript qui évaluent leurs arguments comme du JavaScript sont désactivées. Cela inclut eval(), l'argument code de setTimeout(), ou le constructeur Function().

Le mot-clé unsafe-eval peut être utilisé pour annuler cette protection, permettant l'évaluation dynamique de chaînes de caractères comme JavaScript.

Voir la section eval() et API similaires du guide CSP pour plus d'informations d'utilisation.

wasm-unsafe-eval

Par défaut, si une CSP contient une directive default-src ou script-src, alors une page ne peut pas compiler du WebAssembly à l'aide de fonctions comme WebAssembly.compileStreaming().

Le mot-clé wasm-unsafe-eval peut être utilisé pour annuler cette protection. Il s'agit d'une alternative bien plus sûre à 'unsafe-eval', car cela n'active pas l'évaluation générale du JavaScript.

unsafe-inline

Par défaut, si une CSP contient une directive default-src ou script-src, alors le JavaScript embarqué n'est pas autorisé à s'exécuter. Cela inclut :

• les balises <script> embarqué
• les attributs de gestionnaire d'évènements embarqué
• les URL javascript:.

De même, si une CSP contient default-src ou une directive style-src, alors le CSS embarqué n'est pas chargé, y compris :

• les balises <style> embarqué
• les attributs style.

Le mot-clé unsafe-inline peut être utilisé pour annuler cette protection, permettant à toutes ces formes d'être chargées.

Voir la section JavaScript embarqué du guide CSP pour plus d'informations d'utilisation.

unsafe-hashes

Par défaut, si une CSP contient une directive default-src ou script-src, alors les attributs de gestionnaire d'évènements embarqués comme onclick et les attributs style embarqués ne sont pas autorisés à s'exécuter.

L'expression 'unsafe-hashes' permet au navigateur d'utiliser des expressions de hachage pour les gestionnaires d'évènements embarqués et les attributs style. Par exemple, une CSP peut contenir une directive comme :

script-src 'unsafe-hashes' 'sha256-cd9827ad...'

Si la valeur de hachage correspond au hachage de la valeur d'un attribut de gestionnaire d'évènements embarqués ou d'un attribut style, alors le code est autorisé à s'exécuter.

<button onclick="transferAllMyMoney()">Transférer tout mon argent</button>

inline-speculation-rules

Par défaut, si une CSP contient une directive default-src ou script-src, alors le JavaScript embarqué n'est pas autorisé à s'exécuter. L'expression 'inline-speculation-rules' permet au navigateur de charger des éléments <script> embarqués qui ont un attribut type de speculationrules.

Voir la section API Speculation Rules pour plus d'informations.

strict-dynamic

Le mot-clé 'strict-dynamic' fait en sorte que la confiance conférée à un script par un nombre unique ou un hachage s'étende aux scripts que ce script charge dynamiquement, par exemple en créant de nouvelles balises <script> à l'aide de Document.createElement() puis en les insérant dans le document avec Node.appendChild().

Si ce mot-clé est présent dans une directive, alors les valeurs d'expression de source suivantes sont toutes ignorées :

• <host-source>
• <scheme-source>
• 'self'
• 'unsafe-inline'

Voir la section Le mot-clé strict-dynamic du guide CSP pour plus d'informations d'utilisation.

report-sample

Si cette expression est incluse dans une directive contrôlant les scripts ou les styles, et que la directive entraîne le blocage par le navigateur de tout script embarqué, style embarqué ou attribut de gestionnaire d'évènements embarqué, alors le rapport de violation généré par le navigateur contient une propriété sample contenant les 40 premiers caractères de la ressource bloquée.

Le CSP dans les workers

En général, les workers ne sont pas régis par la politique de sécurité du contenu du document (ou du worker parent) qui les a créés. Pour définir une politique de sécurité du contenu pour le worker, il faut définir un en-tête de réponse Content-Security-Policy pour la requête qui a demandé le script du worker.

L'exception à cette règle concerne le cas où l'origine du script du worker est un identifiant global unique (par exemple, si son URL utilise un schéma de type data ou blob). Dans ce cas, le worker hérite de la politique de sécurité du contenu du document ou du worker qui l'a créé.

Gérer plusieurs politiques de sécurité

Le mécanisme CSP permet d'indiquer plusieurs politiques pour une ressource, notamment avec l'en-tête Content-Security-Policy, l'en-tête Content-Security-Policy-Report-Only et l'élément <meta>.

Vous pouvez utiliser l'en-tête Content-Security-Policy plusieurs fois, comme dans l'exemple ci-dessous. Portez une attention particulière à la directive connect-src ici. Même si la deuxième politique autorise la connexion, la première politique contient connect-src 'none'. Ajouter des politiques supplémentaires ne peut que restreindre davantage les capacités de la ressource protégée, ce qui signifie qu'aucune connexion n'est autorisée et, en tant que politique la plus stricte, connect-src 'none' est appliquée.

Content-Security-Policy: default-src 'self' http://exemple.com;
                          connect-src 'none';
Content-Security-Policy: connect-src http://exemple.com/;
                          script-src http://exemple.com/

Exemples

Désactiver le code embarqué non sûr et n'autoriser que les ressources HTTPS

Cet en-tête HTTP définit la politique par défaut pour n'autoriser le chargement des ressources (images, polices, scripts, etc.) qu'en HTTPS. Comme les directives unsafe-inline et unsafe-eval ne sont pas définies, les scripts embarqués sont bloqués.

Content-Security-Policy: default-src https:

Les mêmes restrictions peuvent être appliquées à l'aide de l'élément HTML <meta>.

<meta http-equiv="Content-Security-Policy" content="default-src https:" />

Autoriser le code embarqué et les ressources HTTPS, mais désactiver les plugins

Cette politique peut être utilisée sur un site existant qui utilise trop de code embarqué pour être corrigé, afin de s'assurer que les ressources sont chargées uniquement par HTTPS et de désactiver les plugins :

Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'

Signaler mais ne pas appliquer les violations lors des tests

Cet exemple applique les mêmes restrictions que l'exemple précédent, mais utilise l'en-tête Content-Security-Policy-Report-Only et la directive report-to. Cette approche est utilisée lors des tests pour signaler les violations sans bloquer l'exécution du code.

Les points de terminaison (URL) vers lesquels envoyer les rapports sont définis à l'aide de l'en-tête de réponse HTTP Reporting-Endpoints.

Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"

Un point de terminaison particulier est ensuite sélectionné comme cible de rapport dans la politique CSP à l'aide de la directive report-to.

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-url/; report-to csp-endpoint

Notez que la directive report-uri est également définie ci-dessus car report-to n'est pas encore largement pris en charge par les navigateurs.

Voir Mise en œuvre de la Content Security Policy (CSP) pour plus d'exemples.

Spécifications

Compatibilité des navigateurs

Voir aussi

• L'en-tête Content-Security-Policy-Report-Only
• La directive CSP report-to
• L'en-tête Reporting-Endpoints
• L'interface API CSPViolationReport
• L'API Reporting.
• Apprendre : Content Security Policy
• Sécurité du contenu dans les WebExtensions
• Adopter une politique stricte ^(angl.)
• Évaluateur CSP ^(angl.) - Évaluer votre politique de sécurité du contenu