# Un modèle de CSP de départ à copier puis resserrer (/fr/blog/csp-starter-template)





La plupart des exemples de politique de sécurité du contenu (CSP) que l'on trouve sont
soit trop permissifs pour protéger quoi que ce soit (`default-src *` avec
`'unsafe-inline'` greffé jusqu'à ce que le site fonctionne), soit trop stricts pour être
déployés sans le casser. Voici un modèle de départ réellement utilisable : un défaut
strict à coller, une version plus forte basée sur un nonce vers laquelle évoluer, et une
fiche pour comprendre chaque ligne avant de la déployer. La seule règle qui rend tout
cela sûr : lancez-le d'abord en Report-Only, à chaque fois.

## La politique de départ [#la-politique-de-départ]

Collez ceci comme header `Content-Security-Policy-Report-Only` et observez ce qu'il
bloquerait avant d'appliquer quoi que ce soit. Report-Only signifie que le navigateur
signale les violations mais ne bloque rien en réalité, donc une ligne trop stricte ne
peut pas casser la page pendant que vous découvrez ce que le site charge vraiment.

```http
Content-Security-Policy-Report-Only:
    default-src 'self';
    script-src 'self';
    style-src 'self';
    img-src 'self' data:;
    font-src 'self';
    connect-src 'self';
    object-src 'none';
    base-uri 'none';
    frame-ancestors 'none';
    report-to csp-endpoint
```

Associez-le à un header `Reporting-Endpoints` pour que les violations aient une
destination, sinon vous avancez à l'aveugle :

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

## La version plus forte, nonce plus strict-dynamic [#la-version-plus-forte-nonce-plus-strict-dynamic]

Le modèle de départ utilise encore une allowlist par host (`'self'`). Une fois que vous
avez retiré les scripts inline et ajouté un nonce par requête, cette version abandonne
entièrement les allowlists de hosts pour les scripts et leur fait confiance par nonce, ce
qui est plus difficile à contourner. Voir
[strict-dynamic expliqué](/fr/blog/strict-dynamic-csp).

```http
Content-Security-Policy:
    default-src 'self';
    script-src 'nonce-r4nd0m' 'strict-dynamic';
    object-src 'none';
    base-uri 'none';
    frame-ancestors 'none';
    report-to csp-endpoint
```

## Fiche par directive [#fiche-par-directive]

Chaque ligne mérite sa place. Les deux que l'on oublie le plus souvent,
`object-src 'none'` et `base-uri 'none'`, sont le renforcement le moins coûteux de toute
la politique.

| Directive                | Pourquoi elle est dans le modèle                                     |
| ------------------------ | -------------------------------------------------------------------- |
| `default-src 'self'`     | Le repli pour tout ce qui n'est pas défini explicitement.            |
| `object-src 'none'`      | Bloque les plugins, ferme un contournement courant.                  |
| `base-uri 'none'`        | Empêche une balise `<base>` injectée de rediriger les URL relatives. |
| `frame-ancestors 'none'` | Protection contre le clickjacking, remplace `X-Frame-Options`.       |
| `img-src 'self' data:`   | Autorise les images data inline, courant et à faible risque.         |
| `report-to csp-endpoint` | Envoie les violations à votre endpoint.                              |

Conservez `object-src 'none'` et `base-uri 'none'` même après être passé à
`'strict-dynamic'` ; ce mot-clé ne gouverne que les scripts, donc ces deux directives
ferment des failles qu'il ne couvre pas.

## Comment le resserrer [#comment-le-resserrer]

1. Déployez en Report-Only et collectez les violations depuis le trafic réel pendant
   quelques jours.
2. Pour chaque ressource bloquée, décidez : la retirer, ou ajouter la source la plus
   étroite qui l'autorise (un host précis, pas un wildcard).
3. Retirez tout [`'unsafe-inline'`](/fr/blog/unsafe-inline-csp) ajouté comme béquille, en
   remplaçant les scripts inline par un nonce ou un hash.
4. Notez le résultat avec le [évaluateur CSP](/tools/csp-evaluator).
5. Quand le flux de reports est propre, passez de `-Report-Only` au header appliqué.
   Voir [enforce comparé à report-only](/fr/blog/csp-enforce-vs-report-only).

<img alt="Les violations issues du trafic réel, regroupées par directive et origine bloquée" src="__img0" width="1365" height="691" />

## Ne resserrez pas à l'aveugle [#ne-resserrez-pas-à-laveugle]

Chaque étape ci-dessus dépend de votre capacité à voir ce que la politique bloque sur de
vraies pages et de vrais navigateurs, pas seulement sur votre poste, où les tiers et les
cas limites n'apparaissent jamais. CentralCSP
[collecte les reports de violation](/fr/docs/platform/monitoring/csp), les regroupe par
directive et par host, et vous montre exactement quelle ligne changer ensuite. Pour tout
script inline que vous devez réellement conserver, générez son hash avec le
[générateur de hash](/tools/csp-hash).

## Étapes suivantes [#étapes-suivantes]

* Le workflow complet : [comment construire une CSP solide](/fr/blog/how-to-build-a-strong-csp).
* Définissez le header pour votre stack : [le header CSP dans chaque framework](/fr/blog/set-csp-header-every-framework).
* Gérez les tiers : [CSP pour les services Google](/fr/blog/csp-for-google-services).

[Resserrez votre CSP avec des reports issus du trafic réel](/register).

## Sources [#sources]

* [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)
* [web.dev, Mitigate XSS with a strict Content Security Policy](https://web.dev/articles/strict-csp)
* [MDN, Content Security Policy guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)
* [OWASP, Content Security Policy cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html)