# Headers (/fr/docs/web-security/policies/content-security-policy/introduction/csp-headers) Une politique de sécurité du contenu (CSP) atteint le navigateur sous la forme d'un header de réponse HTTP. Vous envoyez la politique sur la réponse, le navigateur la lit, et à partir de là il applique les règles à la page. Cette page couvre les deux headers de livraison, la façon dont la politique signale les violations, les limites de la livraison par ``, et ce qui se passe quand une réponse transporte plus d'une politique. Pour le contenu de la politique lui-même, voir les [directives](/fr/docs/web-security/policies/content-security-policy/introduction/csp-directives) et les [valeurs](/fr/docs/web-security/policies/content-security-policy/introduction/csp-values) qu'elles acceptent. Le header d'application dans sa forme la plus simple : ```http Content-Security-Policy: default-src 'self' ``` ## Enforce ou report-only [#enforce-ou-report-only] Deux headers livrent une politique. Ils prennent exactement la même syntaxe ; la seule différence est ce que le navigateur fait d'une violation. | Header | Statut | Ce que fait le navigateur | | --------------------------------------------------------------------------------------------------------- | ------ | ---------------------------------------------------------- | | `Content-Security-Policy` | ✅ Bon | Applique la politique : bloque la violation et la signale. | | [Content-Security-Policy-Report-Only](/fr/docs/web-security/policies/content-security-policy/report-only) | ✅ Bon | Signale la violation mais ne la bloque pas. | Le mode report-only vous laisse observer ce qu'une politique casserait avant de l'activer. Vous déployez la politique sur le header report-only, collectez les rapports, corrigez ce que la politique aurait bloqué, puis déplacez la même chaîne vers le header d'application. Une politique report-only a besoin d'un endpoint de reporting pour être utile, puisque signaler est tout ce qu'elle fait. ```http Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint ``` Une réponse peut transporter à la fois une politique appliquée et une politique report-only, ce qui vous permet d'appliquer une base connue et saine tout en testant une politique plus stricte en parallèle. ## Comment la politique signale [#comment-la-politique-signale] Une politique pointe le navigateur vers un endpoint avec l'une de deux directives. * `report-to` nomme un groupe de reporting. L'URL du groupe vit dans un header séparé, [Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints), qui fait partie de la Reporting API. C'est le mécanisme actuel. Voir la page CSP [report-to](/fr/docs/web-security/policies/content-security-policy/directives/report-to). * `report-uri` poste les rapports directement vers une URL. C'est le mécanisme historique, ignoré là où `report-to` est pris en charge, c'est-à-dire désormais tous les navigateurs actuels (Chrome, Edge, Safari et Firefox). `report-to` est le mécanisme principal ; ne gardez `report-uri` à côté que pour couvrir les anciennes versions de navigateurs non mises à jour. Le header moderne `Reporting-Endpoints` s'associe à `report-to` ; l'ancien header [Report-To](/fr/docs/web-security/reporting-api/headers/report-to) est un mécanisme distinct et déprécié dont la CSP n'a plus besoin (il ne reste requis que pour NEL). ```http Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com" ``` ```http Content-Security-Policy: default-src 'self'; report-uri https://.report.centralcsp.com; report-to csp-endpoint ``` Les deux chemins de livraison produisent des formes de rapport différentes : des noms de champs avec tirets pour `report-uri` et du camelCase pour `report-to`. Les deux arrivent comme un [rapport de violation CSP](/fr/docs/web-security/reporting-api/reports/csp-violation), que CentralCSP collecte et normalise. Pour confirmer que votre endpoint est bien câblé, lancez le [vérificateur Reporting API](/tools/reporting-api). ## Livraison via une balise meta [#livraison-via-une-balise-meta] Vous pouvez aussi livrer une politique en HTML avec une balise `` dans le `` du document, ce qui est utile quand vous ne pouvez pas définir de headers de réponse. ```html ``` Une politique `` est plus limitée qu'un header. Elle ne peut pas faire de report-only. Elle ne peut pas utiliser `report-uri`, `report-to`, `frame-ancestors` ni `sandbox`. Elle doit apparaître dans le `` et ne régit que le contenu qui vient après elle dans le document. Préférez le header HTTP partout où vous pouvez en définir un. ## Comment plusieurs politiques se combinent [#comment-plusieurs-politiques-se-combinent] Quand une réponse transporte plus d'une politique appliquée, le navigateur les applique toutes, et une ressource doit satisfaire chacune pour se charger. Les politiques se combinent par intersection, donc la règle effective est la plus restrictive de l'ensemble. Ajouter une politique ne peut donc que resserrer le résultat, jamais le relâcher. Une seconde politique `script-src 'self'` ne réautorisera pas un hôte qu'une première politique `script-src 'none'` a déjà bloqué. Chaque politique est aussi évaluée indépendamment pour le reporting, donc une violation peut produire des rapports vers plusieurs endpoints. ## Recommandation [#recommandation] Faites tourner les deux headers ensemble : appliquez la politique en laquelle vous avez confiance aujourd'hui, et testez chaque resserrement dans une politique report-only avant de le promouvoir. Câblez le reporting via `report-to` et [Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints), que tous les navigateurs actuels prennent désormais en charge. ```http Reporting-Endpoints: csp-endpoint="https://.report.centralcsp.com" ``` ```http Content-Security-Policy: script-src 'nonce-{RANDOM}' 'strict-dynamic'; object-src 'none'; base-uri 'none'; report-to csp-endpoint ``` ```http Content-Security-Policy-Report-Only: script-src 'nonce-{RANDOM}' 'strict-dynamic'; connect-src 'self'; report-to csp-endpoint ``` Le resserrement par étapes avec une politique report-only en miroir est la façon dont le [guide de CSP stricte de web.dev](https://web.dev/articles/strict-csp) recommande de déployer une politique, et il évite un incident de production à chaque changement. ## FAQ [#faq] ### Quelle est la différence entre une CSP enforce et report-only ? [#quelle-est-la-différence-entre-une-csp-enforce-et-report-only-] `Content-Security-Policy` bloque une violation et la signale ; `Content-Security-Policy-Report-Only` la signale seulement, ce qui vous permet de tester une politique avant de l'appliquer. Voyez [enforce vs report-only](/fr/blog/csp-enforce-vs-report-only) pour le workflow de déploiement complet. ### Puis-je définir une CSP dans une balise meta ? [#puis-je-définir-une-csp-dans-une-balise-meta-] Oui pour la plupart des directives, mais une balise `` ne peut pas faire de report-only et ignore `report-uri`, `report-to`, `frame-ancestors` et `sandbox`. Voyez [balises meta vs headers](/fr/blog/csp-meta-tags-vs-headers) pour savoir quand utiliser chacun. ## Voir aussi [#voir-aussi] * [Ce qu'est la CSP](/fr/docs/web-security/policies/content-security-policy/introduction/what-is-csp) * [Content-Security-Policy-Report-Only](/fr/docs/web-security/policies/content-security-policy/report-only) * [Directive report-to](/fr/docs/web-security/policies/content-security-policy/directives/report-to) * [Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints) * [X-Frame-Options](/fr/docs/web-security/security-headers/x-frame-options) * [Rapport de violation CSP](/fr/docs/web-security/reporting-api/reports/csp-violation) ## Sources [#sources] * [MDN, Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy) * [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/) * [web.dev, Mitigate cross-site scripting with a strict CSP](https://web.dev/articles/strict-csp)