# Ce que c'est (/fr/docs/web-security/policies/content-security-policy/introduction/what-is-csp)



Une politique de sécurité du contenu (CSP) est une liste d'autorisation que vous
envoyez sous forme de header de réponse HTTP pour indiquer au navigateur quelles
ressources une page peut charger et exécuter. Le navigateur lit la politique et
refuse tout ce qui en sort : un script provenant d'un hôte non approuvé, un
`<script>` inline injecté par un attaquant, un formulaire qui envoie ses données
vers un domaine tiers. Vous déclarez les règles ; le navigateur les applique côté
client.

```mermaid
flowchart LR
  A["Le navigateur reçoit<br/>la politique"] --> B["Vérifie chaque ressource<br/>selon sa directive"]
  B --> C["Autorisée :<br/>la ressource s'exécute"]
  B --> D["Bloquée : refusée<br/>et signalée"]
```

CentralCSP n'applique pas la politique. C'est le navigateur qui l'applique.
CentralCSP collecte les rapports de violation que le navigateur envoie, en
construit un inventaire de scripts, et transforme ce flux en monitoring, alerting
et preuves. C'est de l'observabilité et de la gestion de politique par-dessus ce
que le navigateur fait déjà, pas un proxy ni un
[pare-feu applicatif web](/solutions/developers).

## À quoi ressemble une politique [#à-quoi-ressemble-une-politique]

Une politique est une chaîne de directives séparées par des points-virgules.
Chaque directive est un nom suivi d'une liste de sources ou de mots-clés, séparés
par des espaces, que la directive autorise. Les noms de directives ne sont pas
sensibles à la casse, et seule la première occurrence d'une directive donnée dans
une politique est utilisée.

```http
Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-r4nd0m';
  object-src 'none';
  base-uri 'none'
```

Cette politique dit que les scripts peuvent provenir de la même origine ou porter
le nonce `r4nd0m`, que les plugins sont bloqués, que la balise `<base>` est
verrouillée, et que tout le reste se rabat sur la même origine. Chaque élément est
détaillé sur sa propre page :
les [directives](/fr/docs/web-security/policies/content-security-policy/introduction/csp-directives)
qui nomment ce qu'il faut contrôler, les [valeurs](/fr/docs/web-security/policies/content-security-policy/introduction/csp-values)
que chaque directive accepte, et les [headers](/fr/docs/web-security/policies/content-security-policy/introduction/csp-headers)
qui transportent la politique jusqu'au navigateur.

## Ce contre quoi elle protège [#ce-contre-quoi-elle-protège]

La CSP est un contrôle de défense en profondeur. Elle ne corrige pas le bug qui
permet à un attaquant d'injecter du contenu ; elle limite ce que cette injection
peut faire une fois en place.

| Menace                                  | Comment la politique aide                                                                                                                                                                                                                                                                                                                                            |
| --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Cross-site scripting (XSS) et injection | Bloquer les scripts inline et externes non approuvés pour que le code injecté ne puisse pas s'exécuter. Utilisez [script-src](/fr/docs/web-security/policies/content-security-policy/directives/script-src).                                                                                                                                                         |
| Clickjacking                            | Contrôler quels sites peuvent encadrer la page avec [frame-ancestors](/fr/docs/web-security/policies/content-security-policy/directives/frame-ancestors).                                                                                                                                                                                                            |
| Contenu mixte                           | Réécrire les URL de sous-ressources non sécurisées en HTTPS avec [upgrade-insecure-requests](/fr/docs/web-security/policies/content-security-policy/directives/upgrade-insecure-requests).                                                                                                                                                                           |
| Exfiltration de données                 | Restreindre où la page peut envoyer des données et poster des formulaires avec [connect-src](/fr/docs/web-security/policies/content-security-policy/directives/connect-src), [form-action](/fr/docs/web-security/policies/content-security-policy/directives/form-action) et [base-uri](/fr/docs/web-security/policies/content-security-policy/directives/base-uri). |

C'est le XSS qui pousse la plupart des équipes à adopter une politique.
Si un attaquant injecte une balise `<script>` dans une page, une
politique bien construite empêche ce script de s'exécuter, parce qu'il n'a pas de
nonce, pas de hash correspondant, et pas d'hôte autorisé. L'injection a quand même
lieu ; le payload ne s'exécute jamais.

## La CSP ne remplace pas l'encodage [#la-csp-ne-remplace-pas-lencodage]

Une politique réduit l'impact d'une injection, elle n'empêche pas l'injection.
Vous avez toujours besoin d'un encodage de sortie contextuel, d'une validation des
entrées, et des autres contrôles côté serveur qui empêchent en amont les données
non fiables d'arriver dans la page. Traitez la politique comme la seconde couche
qui contient une erreur de la première.

## La recommandation de la CSP stricte [#la-recommandation-de-la-csp-stricte]

Les listes d'autorisation d'hôtes sont difficiles à bien régler. Elles ont
tendance à s'allonger, elles autorisent souvent des domaines qui hébergent
eux-mêmes du contenu contrôlable par un attaquant, et une seule entrée permissive
peut mettre en échec toute la politique. La recommandation actuelle, exposée dans
le [guide web.dev sur la CSP stricte](https://web.dev/articles/strict-csp),
consiste à ne plus autoriser des hôtes pour les scripts, mais à faire confiance à
des scripts précis.

Une politique stricte repose sur quatre éléments :

* Un [nonce ou un hash](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce)
  sur `script-src` pour que seuls les scripts que vous avez marqués puissent
  s'exécuter.
* [strict-dynamic](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords),
  pour qu'un script de confiance puisse charger les scripts dont il a besoin sans
  que vous listiez chaque hôte. En sa présence, les entrées d'hôte et de scheme
  sont ignorées.
* `object-src 'none'` pour supprimer l'exécution de scripts via les plugins.
* `base-uri 'none'` pour bloquer l'injection de balise `<base>`, qui peut sinon
  rediriger toutes les URL de scripts relatives de la page.

Une politique de base complète définit ces éléments, puis explicitement toutes les
autres directives, y compris les directives fetch qui se rabattraient sinon sur
`default-src`, pour que rien ne reste implicite et que le navigateur signale les
violations à votre endpoint :

```http
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
```

```http
Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
```

Générez un nouveau nonce `{RANDOM}` à chaque réponse et placez la même valeur sur
chaque `<script>` de confiance. N'assouplissez une directive que lorsque le site
l'exige (un CDN d'images dans `img-src`, une frame que vous intégrez dans
`frame-src`) ; gardez le reste.

Vous pouvez confronter un brouillon de politique à ces règles avec
l'[évaluateur CSP](/tools/csp-evaluator), et relever les headers actuels d'un site
en production avec le [scanner CSP](/tools/csp-scanner). Pour une construction
pas à pas, le blog détaille la démarche dans
[débuter avec CSP](/fr/blog/get-started-with-csp) et
[construire une CSP solide](/fr/blog/how-to-build-a-strong-csp).

## Comment CentralCSP s'intègre [#comment-centralcsp-sintègre]

Une politique stricte se déploie le plus facilement par étapes, en commençant en
mode report-only pour observer ce qui casserait avant d'appliquer quoi que ce
soit. Le navigateur envoie un
[rapport de violation CSP](/fr/docs/web-security/reporting-api/reports/csp-violation) pour
chaque blocage, et CentralCSP collecte ce flux, le déduplique et fait remonter ce
qu'il faut corriger. Les mêmes rapports alimentent un inventaire de scripts, pour
que vous puissiez voir chaque script qui tourne sur une page et déployer la
politique sans avancer à l'aveugle. Consultez la
[suite CSP](/platform/csp-builder) pour l'ensemble des fonctionnalités.

## FAQ [#faq]

### Qu'est-ce qu'une politique de sécurité du contenu ? [#quest-ce-quune-politique-de-sécurité-du-contenu-]

Une politique de sécurité du contenu est une liste d'autorisation que vous envoyez
en header de réponse HTTP pour indiquer au navigateur quelles ressources une page
peut charger et exécuter. Le navigateur lit la politique et refuse tout ce qui en
sort : un hôte de script non approuvé, un script inline injecté, un formulaire qui
envoie ses données vers un domaine tiers. Vous déclarez les règles ; le navigateur
les applique.

### La CSP arrête-t-elle tous les XSS ? [#la-csp-arrête-t-elle-tous-les-xss-]

Non. La CSP est le contrôle le plus fort dans le navigateur contre le XSS, mais
elle limite ce qu'une injection peut faire plutôt que d'empêcher l'injection
elle-même. Une politique solide empêche un script injecté de s'exécuter parce qu'il
n'a ni nonce, ni hash, ni hôte autorisé, mais vous avez toujours besoin d'un
encodage de sortie contextuel et de Trusted Types pour tenir les données non
fiables hors de la page.

### La CSP est-elle difficile à mettre en place ? [#la-csp-est-elle-difficile-à-mettre-en-place-]

Pas si vous la déployez par étapes. Les listes d'autorisation d'hôtes sont
difficiles à bien régler, la recommandation actuelle est donc une politique stricte
fondée sur un nonce ou un hash plus `strict-dynamic`. Déployez-la d'abord en mode
report-only pour voir ce qui casserait, puis basculez la même chaîne dans le
header d'application. Le
[guide de la CSP solide](/fr/blog/how-to-build-a-strong-csp) détaille la
construction.

## Voir aussi [#voir-aussi]

* [Directives CSP](/fr/docs/web-security/policies/content-security-policy/introduction/csp-directives)
* [Valeurs CSP](/fr/docs/web-security/policies/content-security-policy/introduction/csp-values)
* [Headers CSP](/fr/docs/web-security/policies/content-security-policy/introduction/csp-headers)
* [Content-Security-Policy-Report-Only](/fr/docs/web-security/policies/content-security-policy/report-only)
* [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)