# 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 poste vers un
domaine étranger. 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. Il s'agit d'observabilité et de gestion de politique par-dessus ce que
le navigateur fait déjà, et non d'un proxy ou d'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 livrent la politique 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). |

Le cas du XSS est la raison pour laquelle la plupart des équipes adoptent 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 d'abord 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 à cesser d'autoriser des hôtes pour les scripts et à faire plutôt
confiance à des scripts individuels.

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 les directives
restantes explicitement, y compris les directives de 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 nonce `{RANDOM}` frais par réponse et placez la même valeur sur chaque
`<script>` de confiance. Ne desserrez une seule directive que lorsque le site en a
besoin (un CDN d'images dans `img-src`, une frame que vous intégrez dans
`frame-src`) ; gardez le reste.

Vous pouvez vérifier un brouillon de politique par rapport à ces règles avec le
[évaluateur CSP](/tools/csp-evaluator), et scanner un site en production pour ses
headers actuels 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
poste vers un domaine étranger. 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 observer ce qui casserait, puis déplacez la même chaîne vers 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)