path: root/files/fr/web/http/csp/index.html

---
title: Content Security Policy (CSP)
slug: Web/HTTP/CSP
tags:
  - CSP
  - Content Security Policy
  - Reference
  - Security
translation_of: Web/HTTP/CSP
---
<div>{{HTTPSidebar}}</div>

<p class="summary"><strong>Une <em>Content Security Policy ({{Glossary("CSP")}})</em> ou stratégie de sécurité du contenu</strong> permet d'améliorer la sécurité des sites web en permettant de détecter et réduire certains types d'attaques, dont les attaques {{Glossary("XSS")}} (<em>Cross Site Scripting</em>) et les injections de contenu. Ces attaques peuvent être utilisées dans divers buts, comme le vol de données, le défacement de site ou la diffusion de <em>malware</em>.</p>

<p>CSP a été conçu pour être complètement rétro-compatible (à l'exception de la version 2 dans laquelle existent des incompatibilités décrites explicitement comme telles ; pour plus d'informations, se référer à <a href="https://www.w3.org/TR/CSP2">la documentation du w3c (en anglais)</a>). D'une part : les navigateurs qui ne prennent pas en charge le CSP fonctionnent parfaitement avec les serveurs qui l'implémentent et inversement. D'autre part, lorsque les sites ne fournissent pas les en-têtes correspondant, les navigateurs utilisent la règle de même origine (<em>same-origin policy</em>) pour les contenus.</p>

<p>Pour activer CSP, vous devez configurer vos serveurs web afin d'ajouter un en-tête (<em>header</em>) HTTP {{HTTPHeader("Content-Security-Policy")}} aux réponses. Vous pouvez rencontrer des documents qui mentionnent <code>X-Content-Security-Policy</code> comme en-tête, il s'agit d'une version obsolète qu'il n'est plus utile de supporter.</p>

<p>Une autre possibilité consiste à utiliser l'élément HTML {{HTMLElement("meta")}} pour configurer la règle, par exemple : <code>&lt;meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';"&gt;</code></p>

<h2 id="Menaces">Menaces</h2>

<h3 id="Réduction_des_attaques_cross_site_scripting_XSS">Réduction des attaques <em>cross site scripting</em> (XSS)</h3>

<p>L'un des objectifs de CSP est la réduction et le rapport d'attaques XSS (injections de contenu). Les attaques XSS exploitent la confiance que les navigateurs ont dans le contenu reçu des serveurs. Des scripts malveillants peuvent être exécutés par le navigateur d'une victime parce que le navigateur fait confiance au serveur qui lui envoie des données même quand le contenu ne vient pas de là où il semble venir.</p>

<p>CSP permet aux administrateurs système de réduire ou éliminer les moyens de réaliser des attaques XSS en permettant de spécifier les domaines autorisés à fournir des scripts pour la page visitée. Un navigateur compatible avec CSP n'exécute que les scripts provenant d'une origine autorisée par les règles CSP reçues et ignore ceux qui ne sont pas autorisés. On peut ainsi bloquer les domaines non autorisés, les scripts <em>inline</em> (inclus dans une page HTML) ou associés à des événements via les attributs HTML dédiés.</p>

<p>Pour un niveau de protection le plus élevé possible, un site qui voudrait qu'aucun script ne puisse être exécuté peut désactiver tout simplement l'exécution de tout script.</p>

<h3 id="Empêcher_les_écoutes_du_trafic">Empêcher les écoutes du trafic</h3>

<p>En plus de restreindre les domaines à partir desquels le contenu peut être chargé, le serveur peut indiquer quels protocoles doivent être utilisés et par exemple forcer l'utilisation de HTTPS afin d'améliorer la sécurité. Une stratégie de sécurité complète pour la transmission des données peut non seulement forcer l'utilisation de TLS via HTTPS mais aussi forcer l'utilisation de <a href="/fr/docs/Web/HTTP/Cookies">cookies sécurisés</a> (qui ne peuvent être envoyés qu'en HTTPS) et indiquer de convertir automatiquement toutes les requêtes qui auraient été faites en HTTP simple en requêtes HTTPS. L'utilisation de l'en-tête {{HTTPHeader("Strict-Transport-Security")}} permet de s'assurer que les navigateurs utilisent obligatoirement des connexions chiffrées en TLS (HTTPS).</p>

<h2 id="Utiliser_CSP">Utiliser CSP</h2>

<p>Configurer une stratégie CSP nécessite d'utiliser un en-tête HTTP {{HTTPHeader("Content-Security-Policy")}} pour une page web et de spécifier une valeur pour contrôler les ressources que le navigateur est autorisé à charger pour cette page. Ainsi, une page qui charge et affiche des images peut autoriser les images stockées n'importe où mais n'autoriser les envois de formulaires que vers certaines adresses.</p>

<h3 id="Créer_votre_règle_CSP">Créer votre règle CSP</h3>

<p>On peut utiliser l'en-tête HTTP {{HTTPHeader("Content-Security-Policy")}} pour définir la règle ainsi :</p>

<pre class="syntaxbox">Content-Security-Policy: <em>règle</em></pre>

<p>La <code>règle</code> est une chaîne de caractères contenant la liste des règles qui constituent la règle CSP.</p>

<h3 id="Écrire_une_règle">Écrire une règle</h3>

<p>Une règle est définie par une série de directives qui décrivent chacune le comportement attendu pour un certain type de contenu ou pour l'ensemble des requêtes. Une règle peut inclure une directive {{CSP("default-src")}} pour la règle par défaut qui s'applique aux ressources pour lesquelles aucune règle n'est définie. Pour les autres types de règle, on pourra se référer à la page {{CSP("default-src")}}. Pour bloquer les scripts intégrés au code HTML (JavaScript <em>inline</em>) et l'utilisation de <code>eval()</code>, une règle doit au moins contenir une directive {{CSP("default-src")}} ou {{CSP("script-src")}}. Pour bloquer les modifications de style intégrées au code HTML (CSS <em>inline</em> avec les attributs HTML {{HTMLElement("style")}}) et l'utilisation des balises <code>style</code>, une règle doit au moins contenir une directive {{CSP("default-src")}} ou {{CSP("style-src")}}.</p>

<h2 id="Exemples_pour_les_cas_courants">Exemples pour les cas courants</h2>

<p>Cette section propose des règles CSP pour les scenarios les plus classiques.</p>

<h3 id="Exemple_1">Exemple 1</h3>

<p>Ici, on souhaite que tout le contenu du site soit fourni par la même origine (on exclut les sous-domaines) :</p>

<pre class="syntaxbox">Content-Security-Policy: default-src 'self';</pre>

<h3 id="Exemple_2">Exemple 2</h3>

<p>Pour un site dont tout le contenu est fourni par le site lui-même ou par les sous-domaines de <code>source-sure.example.net</code> (qui peut être un autre site) :</p>

<pre class="syntaxbox">Content-Security-Policy: default-src 'self' *.source-sure.example.net</pre>

<h3 id="Exemple_3">Exemple 3</h3>

<p>Pour un site dont les images peuvent venir de n'importe où, les musiques et vidéos de <code>toto.local</code> ou <code>tata.local</code>, les scripts par <code>scripts.local</code> :</p>

<pre class="syntaxbox">Content-Security-Policy: default-src 'self'; img-src *; media-src toto.local tata.local; script-src scripts.local</pre>

<p>Ici, les contenus doivent par défaut venir de la même origine que la page avec les exceptions précédemment décrites. Cela peut permettre aux utilisateurs d'afficher des images quelconques, mais de ne faire confiance qu'à certains domaines pour les musiques, vidéos et scripts.</p>

<h3 id="Exemple_4">Exemple 4</h3>

<p>Pour un site dont les données sont critiques/privées et pour lequel toutes les données devraient être transmises en HTTPS depuis un domaine précis :</p>

<pre class="syntaxbox">Content-Security-Policy: default-src https://confidentiel.example.net</pre>

<p>Cette règle force l'utilisation de HTTPS et exclut tout usage de contenu ne venant pas de <code>https://confidentiel.example.net</code>.</p>

<h3 id="Exemple_5">Exemple 5</h3>

<p>Pour un webmail qui permet d'afficher des mails incluant de l'HTML, des images provenant de n'importe où mais pas de JavaScript ou d'autres contenus potentiellement dangereux :</p>

<pre class="syntaxbox">Content-Security-Policy: default-src 'self'; img-src *; child-src: *</pre>

<p>On notera que dans cet exemple, on n'a pas de directive {{CSP("script-src")}}. C'est la directive <code>default-src</code> qui indique le comportement par défaut et donc qui limite le chargement des scripts à l'origine.</p>

<h2 id="Tester_une_règle_CSP">Tester une règle CSP</h2>

<p>Pour faciliter le déploiement de CSP, on peut configurer le serveur afin de rapporter uniquement les violations de règle sans appliquer réellement la règle. Ainsi, on peut s'assurer que la règle ne bloque pas les usages du site en récupérant les rapports de violation de la règle en test. On peut aussi tester des modifications d'une règle en place via ce même mécanisme.</p>

<p>Pour cela, il suffit d'utiliser l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}}, comme cela :</p>

<pre class="syntaxbox">Content-Security-Policy-Report-Only: <em>règle</em> </pre>

<p>Si les en-têtes HTTP {{HTTPHeader("Content-Security-Policy-Report-Only")}} et {{HTTPHeader("Content-Security-Policy")}} sont tous deux présents dans la réponse du serveur, les deux règles seront respectées, ce qui permet le test d'une nouvelle règle quand il y en a déjà une en place.</p>

<p>La règle indiquée par <code>Content-Security-Policy</code> est appliquée tandis que celle fourni par <code>Content-Security-Policy-Report-Only</code> génère des rapports mais n'est pas appliquée.</p>

<p>Si une règle contient une directive {{CSP("report-uri")}} valide, les navigateurs qui prennent en charge CSP doivent envoyer un rapport pour chaque violation de la règle qu'ils détectent.</p>

<h2 id="Gérer_les_rapports">Gérer les rapports</h2>

<p>Par défaut, les violations de la règle de sécurité ne sont pas rapportées. Pour avoir des rapports de violation, il faut fournir directive {{CSP("report-uri")}} avec au moins une URL valide à laquelle envoyer les rapports :</p>

<pre class="syntaxbox">Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi</pre>

<p>Il faut également configurer le serveur qui doit recevoir les rapports pour traiter les rapports en question et par exemple les stocker afin de les consulter.</p>

<h2 id="Syntaxe_des_rapports_de_violation">Syntaxe des rapports de violation</h2>

<p>Le rapport est un objet JSON qui contient :</p>

<dl>
 <dt><code>blocked-uri</code></dt>
 <dd>L'URI de la ressource dont le chargement a été bloqué à cause du CSP. Si l'URI bloqué provient d'une origine différente de celle indiquée via <code>document-uri</code>, l'URI bloqué est tronqué et ne contient que le schéma, l'hôte et le port.</dd>
 <dt><code>disposition</code></dt>
 <dd>La chaîne <code>"report"</code> si l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}} a été utilisée ou <code>"enforce"</code> si <code>Content-Security-Policy</code> a été utilisée.</dd>
 <dt><code>document-uri</code></dt>
 <dd>L'URI du document pour lequel la violation a eu lieu.</dd>
 <dt><code>effective-directive</code></dt>
 <dd>La directive dont le non-respect a entraîné la violation.</dd>
 <dt><code>original-policy</code></dt>
 <dd>La règle telle qu'indiquée dans l'en-tête HTTP <code>Content-Security-Policy</code>.</dd>
 <dt><code>referrer</code></dt>
 <dd>Le <em>referrer</em> du document pour lequel la violation a eu lieu.</dd>
 <dt><code>script-sample</code></dt>
 <dd>Les 40 premiers caractères du script, du gestionnaire d'évènement ou du style qui a entraîné la violation.</dd>
 <dt><code>status-code</code></dt>
 <dd>Le code de statut HTTP de la ressource sur laquelle l'objet global a été instancié.</dd>
 <dt><code>violated-directive</code></dt>
 <dd>Le nom de la directive, dans la règle, qui n'a pas été respectée.</dd>
</dl>

<h2 id="Exemple_de_rapport_de_violation_de_règle">Exemple de rapport de violation de règle</h2>

<p>Si l'on considère une page <code>http://example.com/connexion.html</code>, qui utilise la règle CSP suivante (qui interdit tout par défaut et autorise les feuilles de style CSS provenant de <code>cdn.example.com</code>) :</p>

<pre class="syntaxbox">Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports</pre>

<p>et qui contient le code HTML suivant :</p>

<pre class="brush: html">&lt;!DOCTYPE html&gt;
&lt;html&gt;
  &lt;head&gt;
    &lt;title&gt;Connectez-vous&lt;/title&gt;
    &lt;link rel="stylesheet" href="css/style.css"&gt;
  &lt;/head&gt;
  &lt;body&gt;
    ... Contenu ...
  &lt;/body&gt;
&lt;/html&gt;</pre>

<p>Dans cette situation, les clients qui visiteraient cette page la verrait avec les styles de base de leur navigateur car les feuilles de style autorisées ne peuvent venir que de <code>cdn.example.com</code> et non du site lui-même (l'origine même de la page) comme <code>&lt;link rel="stylesheet" href="css/style.css"&gt;</code> l'indique au navigateur. En outre, un navigateur (qui supporte CSP) enverrait le rapport de violation de règle CSP suivant à l'adresse <code>http://example.com/_/csp-reports</code> à chaque visite de la page dont il est question :</p>

<pre>{
  "csp-report": {
    "document-uri": "http://example.com/connexion.html",
    "referrer": "",
    "blocked-uri": "http://example.com/css/style.css",
    "violated-directive": "style-src cdn.example.com",
    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
  }
}</pre>

<p>Comme vous pouvez le constater, le rapport inclus l'URI complète de la ressource dans <code>blocked-uri</code>. Ce n'est le cas en général. Ainsi, si la page avait essayé de charger la feuille de style <code>http://anothercdn.example.com/stylesheet.css</code>, le navigateur aurait indiqué seulement <code>"blocked-uri": "http://anothercdn.example.com/"</code>, c'est à dire l'origine et non l'URI complète car l'origine de la feuille bloquée est différente de l'origine du site lui-même. La spécification de la CSP, <a href="http://www.w3.org/TR/CSP/#security-violation-reports">disponible en anglais sur le site du W3C</a>, explique les raisons de ce comportement qui peut surprendre de prime abord. En résumé, ce comportement évite les risques de diffuser des informations confidentielles qui pourraient être incluses dans les URI des ressources provenant d'autres origines.</p>

<h2 id="Compatibilité_des_navigateurs">Compatibilité des navigateurs</h2>

<p class="hidden">La matrice de compatibilité de cette page est générée depuis le dépôt Git https://github.com/mdn/browser-compat-data. Si vous voulez contribuer en modifiant ces données, merci de faire une <em>pull request</em> sur Github.</p>

<p>{{Compat("http.headers.csp")}}</p>

<p><em>Il existe une incompatibilité spécifique dans certaines versions de Safari : si un en-tête <code>Content-Security-Policy</code> est défini mais qu'il n'y a pas d'en-tête <code>Same-Origin</code> , le navigateur bloquera le contenu du site courant et celui de l'extérieur en indiquant que la stratégie ne permet pas d'avoir ce contenu.</em></p>

<h2 id="Voir_aussi">Voir aussi</h2>

<ul>
 <li>{{HTTPHeader("Content-Security-Policy")}}</li>
 <li>{{HTTPHeader("Content-Security-Policy-Report-Only")}}</li>
 <li><a href="/fr/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy">L'utilisation de CSP pour les WebExtensions.</a></li>
 <li>
  <p><a href="/fr/docs/Web/HTTP/Headers/Content-Security-Policy#Utilisation_du_CSP_dans_les_web_workers">La gestion de CSP dans les web workers</a></p>
 </li>
</ul>