# Headers (/fr/docs/web-security/policies/content-security-policy/introduction/csp-headers) Une politique de sécurité du contenu (CSP) parvient au navigateur dans un header de réponse HTTP. Vous envoyez la politique dans la réponse, le navigateur la lit, puis il applique les règles à la page. Cette page couvre les deux headers qui la transportent, la façon dont la politique signale les violations, les limites de la balise ``, 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 transportent une politique. Ils prennent exactement la même syntaxe ; seul change 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 voir ce qu'une politique casserait avant de l'activer. Vous déployez la politique dans le header report-only, collectez les rapports, corrigez ce que la politique aurait bloqué, puis basculez la même chaîne dans le header d'application. Une politique report-only n'a d'intérêt qu'avec un endpoint de reporting, puisqu'elle ne fait rien d'autre que signaler. ```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 éprouvée tout en testant une politique plus stricte en parallèle. ## Comment la politique signale [#comment-la-politique-signale] Une politique indique au navigateur où envoyer ses rapports avec l'une des deux directives suivantes. * `report-to` nomme un groupe de reporting. L'URL du groupe est déclarée dans un header à part, [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` envoie les rapports directement à 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` en complément que pour les navigateurs anciens qui n'ont pas été mis à jour. Le header moderne `Reporting-Endpoints` va de pair avec `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 produisent des formes de rapport différentes : des noms de champs avec tirets pour `report-uri`, du camelCase pour `report-to`. Dans les deux cas vous recevez un [rapport de violation CSP](/fr/docs/web-security/reporting-api/reports/csp-violation), que CentralCSP collecte et normalise. Pour vérifier que votre endpoint est bien branché, lancez le [vérificateur Reporting API](/tools/reporting-api). ## Livraison via une balise meta [#livraison-via-une-balise-meta] Vous pouvez aussi transmettre une politique en HTML avec une balise `` dans le `` du document, pratique quand vous n'avez pas la main sur les 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] Utilisez les deux headers ensemble : appliquez la politique dont vous êtes sûr aujourd'hui, et testez chaque resserrement dans une politique report-only avant de le promouvoir. Branchez le reporting sur `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 ``` Resserrer par étapes avec une politique report-only en miroir, c'est le déploiement que recommande le [guide de CSP stricte de web.dev](https://web.dev/articles/strict-csp), et ça vous é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)