CSP ne répare pas une XSS

CSP est une excellente couche de défense. Ce n'est pas un correctif XSS.

Cette phrase mérite d'être répétée parce qu'elle évite beaucoup de mauvaises discussions après un audit. Une Content Security Policy peut empêcher l'exécution d'un script inline, bloquer une origine externe, limiter les handlers dangereux, imposer des nonces ou désactiver certains vieux comportements. Très bien. Mais si une application injecte toujours une donnée utilisateur dans le DOM sans encodage adapté, la vulnérabilité existe encore.

Elle est juste moins commode à exploiter dans certaines conditions.

Une politique stricte change le risque, pas la cause

Une bonne CSP ressemble souvent à ceci dans l'esprit :

script-src 'self' 'nonce-...';
object-src 'none';
base-uri 'none';
frame-ancestors 'none';

Le détail dépend de l'application, des intégrations, du rendu serveur, des analytics et parfois de vieux widgets qu'on préférerait oublier. Le principe reste le même : réduire les surfaces d'exécution et rendre les injections plus difficiles à transformer en code actif.

Mais la cause racine d'une XSS reste ailleurs : une donnée non fiable est interprétée dans un contexte actif. Tant que ce flux existe, le correctif principal doit porter sur l'encodage, la sanitization ou l'usage d'API sûres.

Les politiques faibles donnent une fausse confiance

Beaucoup de CSP en production sont décoratives. On voit encore des politiques avec 'unsafe-inline', des allowlists énormes, des domaines CDN trop larges, ou des scripts legacy qui forcent des exceptions permanentes. Parfois la politique est uniquement en Content-Security-Policy-Report-Only depuis deux ans.

Le navigateur fait exactement ce qu'on lui demande. Si la politique autorise presque tout, elle bloque presque rien.

Dans un test avec xsspayloads, il est utile de noter non seulement le comportement du payload, mais aussi les violations CSP observées dans la console. Une violation peut confirmer qu'une injection atteint un contexte intéressant même si l'exécution est bloquée. C'est une information précieuse pour prioriser, surtout quand le correctif applicatif est encore à faire.

Attention aux rapports CSP

Les endpoints de reporting CSP sont bruyants. Extensions navigateur, vieux navigateurs, proxys d'entreprise, outils d'accessibilité, scripts tiers : tout peut générer des événements. Une équipe qui active le reporting sans filtrage se retrouve vite avec une file de logs inutilisable.

Le bon usage consiste à corréler les rapports avec des routes, des releases et des changements précis. Sinon, on finit par ignorer les alertes.

La bonne recommandation

Dans un rapport, il faut séparer les niveaux :

• corriger l'injection avec un encodage ou une sanitization adaptée au contexte ;
• durcir CSP pour réduire l'impact d'une régression future ;
• supprimer les exceptions inutiles comme 'unsafe-inline' quand c'est possible ;
• surveiller les violations exploitables sans transformer le reporting en décharge.

CSP est une ceinture de sécurité. Elle sauve des journées. Mais personne de sérieux ne corrige des freins cassés en ajoutant une meilleure ceinture.