# Comment corriger les constats CSP de SecurityScorecard (/fr/blog/fix-securityscorecard-csp-findings)



Un constat [SecurityScorecard](https://securityscorecard.com/) au sujet de votre politique de sécurité du contenu (CSP) est corrigeable sans casser le site. SecurityScorecard lit les headers de réponse qu'une page en direct renvoie et note la CSP qu'il trouve, de sorte que chaque constat correspond à une faiblesse précise dans la chaîne du header. La correction fiable pour chacun d'eux a la même forme : déployez la politique que vous voulez en report-only, observez le trafic réel, resserrez à partir des preuves, puis appliquez. Cet article prend chaque constat CSP de SecurityScorecard et montre le changement de header concret qui l'efface.

SecurityScorecard remonte ces constats CSP sous le facteur Application Security. Il charge votre domaine, capture la réponse, et vérifie les security headers qu'il voit, dont la CSP. Il n'envoie pas d'attaques forgées ; il lit ce que la page sert déjà. Cela a une conséquence qui vaut la peine d'être posée d'emblée : le scanner note le header appliqué sur votre site en direct, alors déployez un header `Content-Security-Policy` appliqué, pas seulement du report-only, pour effacer un constat de CSP manquante ou faible. Le report-only est la façon de construire la politique en toute sécurité avant de l'appliquer.

## Les constats CSP de SecurityScorecard et ce que chacun signifie [#les-constats-csp-de-securityscorecard-et-ce-que-chacun-signifie]

SecurityScorecard remonte ces constats sous le facteur Application Security. La formulation exacte sur votre carte de score peut différer, mais ils se rangent dans quelques groupes reconnaissables.

* **Une politique de sécurité du contenu manquante.** SecurityScorecard signale une CSP manquante comme un problème Application Security de gravité élevée sur l'hôte évalué.
* **Content Security Policy contains broad directives.** Une directive utilise un joker ou une source trop large comme `*`, un schéma nu, `'unsafe-inline'` ou `'unsafe-eval'`.
* **Site Does Not Use Best Practices Against Embedding of Malicious Content.** Aucun contrôle de framing sur la page, c'est-à-dire une directive `frame-ancestors` ou un header `X-Frame-Options` manquants.

Si vous suivez aussi une note BitSight, les mêmes faiblesses sous-jacentes y apparaissent sous des noms différents et un modèle de notation différent. Les spécificités de BitSight, le changement RAU25, les niveaux de gravité des directives, se trouvent dans [comment corriger les constats CSP de BitSight](/fr/blog/fix-bitsight-csp-findings). Cet article reste du côté de SecurityScorecard. Le header de remédiation est le même ; seule la dénomination de la carte de score diffère.

## Le workflow de correction [#le-workflow-de-correction]

Chaque constat ci-dessus se résout avec une seule séquence : déployer strict en report-only, collecter les rapports de violation, resserrer, puis appliquer.

```mermaid
flowchart LR
  A["Report-Only"] --> B["Collect reports"]
  B --> C["Tighten"]
  C --> D["Enforce"]
```

### 1. Déployez une politique stricte en report-only [#1-déployez-une-politique-stricte-en-report-only]

Commencez par la politique que vous voulez obtenir à terme, mais envoyez-la sur le header `Content-Security-Policy-Report-Only`. Le navigateur analyse la politique et signale ce qu'il bloquerait, mais ne bloque rien, vous pouvez donc déployer une politique stricte sur du trafic réel sans risquer une page cassée.

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

### 2. Pointez les rapports vers un endpoint [#2-pointez-les-rapports-vers-un-endpoint]

Les rapports n'aident que s'ils sont livrés quelque part. Déclarez un endpoint de reporting avec le header de réponse `Reporting-Endpoints`, puis référencez son nom depuis la directive `report-to` dans la politique.

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

Vous pouvez mettre en place l'endpoint et un tableau de bord pour les rapports avec [CentralCSP](/register), qui ingère les rapports de violation CSP et les transforme en un inventaire de scripts et une vue par directive plutôt qu'en JSON brut.

### 3. Collectez les rapports de violation [#3-collectez-les-rapports-de-violation]

Laissez la politique report-only tourner sur du trafic réel. Triez chaque ressource bloquée dans deux piles : légitime (quelque chose dont la page a besoin) et indésirable (une ressource injectée ou obsolète que vous ne voulez pas). Vous autorisez la première pile et laissez la seconde bloquée. Collectez assez longtemps pour capturer l'usage réel avant de faire confiance à la liste.

### 4. Resserrez la politique, un constat à la fois [#4-resserrez-la-politique-un-constat-à-la-fois]

C'est ici que vous retirez les patterns signalés par SecurityScorecard, à l'aide des preuves des rapports. Chaque constat correspond à une modification concrète.

**Une politique de sécurité du contenu manquante.** Ajoutez la politique. Déplacez-la de `Content-Security-Policy-Report-Only` vers le header d'application `Content-Security-Policy` une fois que le flux de rapports est silencieux. Le scanner lit le header appliqué sur votre site en direct, donc une politique appliquée, pas seulement du report-only, est ce qui efface ce constat.

**Content Security Policy contains broad directives.** Remplacez tout `*` isolé et toute source de schéma `http:` nue par les hôtes spécifiques que vos rapports vous montrent réellement chargés. Une source joker réduit à néant la directive, et les rapports vous disent exactement quelles origines lister à la place.

```diff
Content-Security-Policy-Report-Only:
-    script-src *;
+    script-src 'self' https://cdn.example.com
```

`'unsafe-inline'` et `'unsafe-eval'` relèvent de ce même constat de directives trop larges, alors retirez-les aussi ici. Les scripts et styles inline sont un vecteur de cross-site scripting (XSS) de premier plan, ce qui explique pourquoi [`'unsafe-inline'`](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords) est signalé. Donnez plutôt à chaque script inline légitime un nonce ou un hash. Quand `script-src` contient un nonce, un hash ou `'strict-dynamic'`, le navigateur ignore entièrement `'unsafe-inline'`, donc retirer le mot-clé ne change rien pour les navigateurs modernes et ne fait que renforcer la politique. La migration complète est dans [pourquoi ne jamais utiliser unsafe-inline dans une CSP](/fr/blog/unsafe-inline-csp).

Externalisez un event handler inline pour qu'il n'ait plus besoin du mot-clé non sûr :

```html
<!-- before: inline handler needs 'unsafe-inline' -->
<button onclick="startCheckout()">Buy</button>
```

```html
<!-- after: external script, no inline handler -->
<button id="buy">Buy</button>
<script src="/js/checkout.js"></script>
```

```javascript
// /js/checkout.js
document.getElementById('buy').addEventListener('click', startCheckout);
```

Pour un bloc inline que vous ne pouvez pas externaliser, attachez un nonce. Le nonce doit avoir au moins 128 bits d'entropie, être en base64, généré par un générateur de nombres aléatoires cryptographiquement sûr, et frais à chaque réponse.

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

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

**Site Does Not Use Best Practices Against Embedding of Malicious Content.** Il s'agit du contrôle de framing. Ajoutez `frame-ancestors 'none'` (ou les origines spécifiques autorisées à vous embarquer) pour contrôler qui peut intégrer la page, et définissez `X-Frame-Options` comme repli hérité pour les clients plus anciens. Gardez `object-src 'none'` et `base-uri 'none'` pour fermer aussi les vecteurs d'injection classiques. Ce sont les directives qu'un scanner attend sur une politique durcie.

```http
Content-Security-Policy:
    object-src 'none';
    base-uri 'none';
    frame-ancestors 'none'
```

### 5. Appliquez [#5-appliquez]

Quand le flux report-only est silencieux, c'est-à-dire quand les seuls rapports restants sont des ressources que vous avez délibérément choisi de ne pas autoriser, déplacez la même politique validée de `Content-Security-Policy-Report-Only` vers le header d'application `Content-Security-Policy`.

```http
Content-Security-Policy:
    script-src 'nonce-{RANDOM}' 'strict-dynamic';
    style-src 'self';
    img-src 'self';
    connect-src 'self';
    object-src 'none';
    base-uri 'none';
    form-action 'self';
    frame-ancestors 'none';
    report-to csp-endpoint
```

Gardez le reporting actif après avoir appliqué. Tout nouveau rapport signifie désormais un vrai blocage en production, ce qui est votre alerte précoce qu'un changement a cassé quelque chose ou que quelqu'un sonde la page.

## Vérifiez la politique avant de la basculer [#vérifiez-la-politique-avant-de-la-basculer]

Avant d'appliquer, faites passer le projet dans l'[évaluateur CSP](/tools/csp-evaluator) pour repérer tout `'unsafe-inline'` restant, les jokers larges ou les schémas nus dans les directives sensibles, et utilisez le [scanner CSP](/tools/csp-scanner) pour confirmer ce que votre hôte en direct envoie actuellement. Pour voir tous les security headers que lit SecurityScorecard, pas seulement la CSP, le [scanner de security headers](/tools/security-headers) vous donne la liste avant-après complète. La [suite CSP](/platform/csp-builder) relie le reporting, le scan et le suivi de politique une fois passée la première correction.

## Où cela vous mène [#où-cela-vous-mène]

Un constat CSP de SecurityScorecard est une lecture de notation de la chaîne de votre header, donc la correction est un changement de header que vous pouvez faire en toute sécurité : déployez strict en report-only, collectez de vrais rapports de violation, resserrez en remplaçant les mots-clés non sûrs et les jokers par des nonces ou des hashes, puis appliquez. Le même header appliqué qui efface le constat est aussi une protection réellement meilleure contre le XSS et l'injection de ressources.

Si le JSON de rapport brut est plus que ce que vous voulez trier à la main, [ouvrez un compte CentralCSP gratuit](/register) pour collecter les rapports, les voir regroupés par directive et par ressource, et suivre la politique dans le temps à mesure que vous la resserrez.

## Sources [#sources]

* [SecurityScorecard, centre d'aide](https://support.securityscorecard.com/)
* [MDN, Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)

## Articles liés [#articles-liés]

* [Comment corriger les constats CSP de BitSight](/fr/blog/fix-bitsight-csp-findings)
* [Pourquoi ne jamais utiliser unsafe-inline dans une CSP](/fr/blog/unsafe-inline-csp)
* [Référence des mots-clés CSP](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords)