Un modèle de CSP de départ à copier puis resserrer

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

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.

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 :

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

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é.

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

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.

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

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' 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.
5. Quand le flux de reports est propre, passez de -Report-Only au header appliqué. Voir enforce comparé à report-only.

Ne resserrez pas à l'aveugle

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, 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.

Étapes suivantes

• Le workflow complet : comment construire une CSP solide.
• Définissez le header pour votre stack : le header CSP dans chaque framework.
• Gérez les tiers : CSP pour les services Google.

Resserrez votre CSP avec des reports issus du trafic réel.

Sources

• W3C, Content Security Policy Level 3
• web.dev, Mitigate XSS with a strict Content Security Policy
• MDN, Content Security Policy guide
• OWASP, Content Security Policy cheat sheet