CSP — autoriser explicitement, plutôt que tout permettre

Partir du trafic réel, pas d’un modèle

Une CSP recopiée d’un article bloque des choses que votre site utilise et autorise des choses qu’il n’utilise pas. La bonne méthode est l’inverse : publier une politique restrictive en mode rapport, laisser le navigateur signaler ce qu’il aurait bloqué, et n’autoriser que ce qui remonte.

unsafe-inline annule presque tout le bénéfice

`script-src 'unsafe-inline'` autorise tout script écrit dans la page — c’est-à-dire précisément ce qu’une injection produit. Une CSP qui le contient reste utile contre les scripts chargés depuis un domaine tiers, mais laisse ouverte la porte principale.

La sortie propre passe par un nonce : le serveur tire une valeur aléatoire par réponse, la place sur ses propres balises `<script>` et dans la directive. Un script injecté ne connaît pas le nonce du jour.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0m'; style-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'

Les directives qu’on oublie

`frame-ancestors 'none'` empêche l’encadrement de votre site dans une page tierce — c’est le remplaçant moderne de X-Frame-Options. `base-uri 'self'` empêche de détourner les URL relatives en injectant une balise `<base>`. `form-action 'self'` empêche qu’un formulaire soit réexpédié ailleurs. Trois lignes qui ferment trois attaques peu spectaculaires et très pratiquées.

Questions fréquentes

Par où commencer si mon site est déjà en production ?

Par Content-Security-Policy-Report-Only avec `default-src 'self'`. Rien n’est bloqué, tout ce qui aurait dû l’être vous est signalé. Quelques jours de trafic réel suffisent à dresser la liste des sources légitimes.

Puis-je garder Google Analytics avec une CSP stricte ?

Oui, en autorisant explicitement ses domaines dans `script-src` et `connect-src`. C’est le genre de source que le mode rapport fait remonter dès le premier jour.