BitSight RAU25 et pourquoi la CSP est désormais notée

Si vous suivez votre note BitSight, un changement entré en vigueur en juillet 2025 modifie la façon dont vos applications web font bouger votre score. BitSight a présenté en avant-première la mise à jour de l'algorithme de notation 2025 (RAU25) le 8 avril 2025, puis l'a déployée en production en juillet 2025. RAU25 a retiré l'ancien vecteur de risque Web Application Headers (WAH) et l'a remplacé par Web Application Security (WAS). WAS reprend le même poids de 5 % que portait WAH dans la note globale.

En résumé : une politique de sécurité du contenu (CSP) faible ou violée peut désormais faire baisser votre note. La CSP est un header de réponse HTTP qui indique au navigateur quels scripts, styles et autres ressources une page est autorisée à charger. Sous WAS, BitSight évalue la qualité de rédaction de cette politique, et certaines directives comptent plus que d'autres. Cet article explique ce qui a changé, comment ce header de sécurité est noté, et comment corriger une politique qui échoue.

Ce qui a changé dans RAU25

WAS n'est pas un simple renommage de WAH. Il conserve les vérifications de headers que portait WAH et y ajoute un ensemble plus large d'évaluations de sécurité applicative, de sorte qu'une CSP faible n'est désormais qu'un signal parmi plusieurs.

Quelques faits à garder en tête :

WAS porte un poids de 5 % dans la note globale, le même poids que portait WAH, c'est donc une part petite mais réelle de votre score.
WAS remplace WAH comme vecteur applicatif noté.
WAS exécute 21 évaluations réparties sur 5 catégories.

Chaque évaluation reçoit une note textuelle, dont BAD, WARN et FAIR font partie, et le vecteur de risque dans son ensemble reçoit une note en lettres de A à F. Corrigez d'abord les constats les plus graves, car ce sont eux qui pèsent le plus sur la note du vecteur.

Comment la politique de sécurité du contenu est notée

BitSight évalue un contrôle nommé "Content Security Policy (CSP) Violations", et le poids d'une violation dépend de la directive qui l'a provoquée. BitSight regroupe les directives par niveaux de gravité.

Gravité élevée : script-src, script-src-elem, style-src-attr, trusted-types, connect-src, worker-src.
Gravité moyenne : frame-ancestors, frame-src, child-src, base-uri, form-action.
Informatif, sans impact négatif : manifest-src, object-src, media-src, style-src-elem, font-src, style-src, img-src, default-src.

Un détail à signaler : BitSight place object-src dans le niveau informatif, alors même que object-src 'none' est largement considéré comme pertinent pour la sécurité. Continuez à le définir quel que soit le classement de BitSight, car il ferme un vrai vecteur d'injection.

Deux directives du niveau de gravité élevée méritent une note. trusted-types n'est pas définie dans CSP niveau 3. Elle provient de la spécification W3C Trusted Types distincte, aux côtés de require-trusted-types-for, et elle n'est appliquée que dans les navigateurs basés sur Chromium comme Chrome et Edge, pas Firefox ni Safari. Ce contrôle ne porte donc de signal que là où le navigateur l'applique.

BitSight note la CSP à partir de la façon dont la politique est écrite, une lecture statique du header et de ses directives. C'est différent d'un rapport de violation CSP, qui est un événement d'exécution que le navigateur envoie lorsqu'une page tente de charger quelque chose que la politique interdit. CentralCSP travaille du côté de l'exécution : il ingère les rapports de violation réellement émis par le navigateur et construit un inventaire de scripts via le CSP hash reporting. Les deux vues se complètent. Une note statique propre et des rapports d'exécution propres vous disent ensemble que la politique est à la fois bien écrite et qu'elle ne casse rien.

Pourquoi la CSP pèse ici

Une politique de sécurité du contenu est le contrôle côté navigateur qui limite quels scripts et ressources une page peut exécuter. C'est l'une des rares défenses qui réduit l'impact du XSS, du clickjacking et d'autres attaques par injection après qu'un attaquant a déjà trouvé un moyen d'accéder à la page. C'est pourquoi BitSight traite une politique faible ou absente comme un vrai constat plutôt que comme une case à cocher manquante.

La façon la plus courante d'affaiblir une politique est 'unsafe-inline'. Elle réactive les scripts inline que la CSP bloque par défaut, ce qui est exactement le comportement sur lequel reposent la plupart des attaques XSS. Si vous partez d'une politique permissive, retirer ce mot-clé est la correction la plus rentable. Pourquoi ne jamais utiliser unsafe-inline dans une CSP détaille la migration vers les nonces et les hashes.

Comment corriger une politique qui échoue

L'objectif est une politique stricte qui ne casse pas le site et ne génère pas de violations. Collectez des données avant d'appliquer quoi que ce soit. Le même workflow efface aussi le constat équivalent chez d'autres fournisseurs de notation, vous pouvez donc corriger les constats CSP de SecurityScorecard de la même manière.

1. Commencez en Report-Only

Déployez d'abord votre projet de politique avec le header Content-Security-Policy-Report-Only. Le navigateur évalue la politique et signale ce qu'il aurait bloqué, sans rien bloquer. Laissez-la tourner une semaine ou deux pour capturer chaque script, style et connexion légitime.

Content-Security-Policy-Report-Only:
    default-src 'self';
    script-src 'self' 'report-sample';
    style-src 'self';
    img-src 'self';
    font-src 'self';
    connect-src 'self';
    object-src 'none';
    base-uri 'none';
    form-action 'self';
    frame-ancestors 'none';
    upgrade-insecure-requests;
    report-uri https://<Endpoint-ID>.report.centralcsp.com

2. Collectez les rapports de violation

Pointez la directive de reporting vers un endpoint qui collecte les rapports, puis lisez ce qui a été bloqué. CentralCSP ingère ces rapports et les regroupe pour que vous puissiez voir, par directive, exactement quelles ressources votre projet de politique refuserait. Cet inventaire est la base sur laquelle vous construisez la vraie politique.

3. Resserrez d'abord les directives à gravité élevée

BitSight note du pire au meilleur, alors concentrez vos efforts là où ça fait bouger le score. Retirez 'unsafe-inline' et 'unsafe-eval' de script-src et des autres directives à gravité élevée, et remplacez le code inline par des fichiers externes, des nonces ou des hashes.

Les deux patterns à remplacer :

<!-- before: inline handler and inline block, both need unsafe-inline -->
<button onclick="submitForm()">Send</button>
<script>
  initWidget();
</script>

<!-- after: external file, allowed by script-src 'self' -->
<button id="send">Send</button>
<script src="/js/app.js"></script>

// app.js, the inline handler moved into an addEventListener call
document.getElementById("send").addEventListener("click", submitForm);
initWidget();

Pour un bloc inline que vous ne pouvez pas déplacer, autorisez-le avec un nonce plutôt qu'avec 'unsafe-inline' :

Content-Security-Policy: script-src 'self' 'nonce-r4nd0m'

<script nonce="r4nd0m">
  initWidget();
</script>

4. Vérifiez la politique avant de l'appliquer

Avant de passer de Report-Only à l'application, faites passer le projet dans l'évaluateur CSP pour repérer les 'unsafe-inline' restants, les jokers larges comme * et les schémas nus comme http: dans les directives sensibles. Corrigez ce qu'il signale ou acceptez le risque en connaissance de cause.

5. Appliquez, puis continuez à surveiller

Passez au header d'application Content-Security-Policy. Gardez la directive de reporting en place pour continuer à recevoir les rapports de violation, et relisez-les après chaque déploiement. Une politique qui passait le mois dernier peut se mettre à échouer dès qu'un nouveau script tiers arrive sur la page, ce qui est la même dérive que BitSight détectera à son prochain scan.

À retenir

RAU25 lie une partie de votre note BitSight à la qualité de rédaction de votre politique de sécurité du contenu, les directives qui exécutent des scripts étant les plus pondérées. Une politique stricte sans 'unsafe-inline', sans jokers larges et sans violations en direct est ce qui maintient cette partie du score en bonne santé. Construisez-la en Report-Only, fondez-la sur de vrais rapports, et continuez à surveiller après l'avoir appliquée.

Pour collecter les rapports de violation et suivre votre politique dans le temps, commencez gratuitement avec CentralCSP.