# script-src-attr (/fr/docs/web-security/policies/content-security-policy/directives/script-src-attr)



La directive `script-src-attr` d'une politique de sécurité du contenu (Content Security Policy, CSP) contrôle les attributs event handler inline, le JavaScript écrit directement dans des attributs HTML tels que `onclick`, `onload` et `onmouseover`. Elle ne couvre pas les éléments `<script>`, ceux-ci relèvent de [`script-src-elem`](/fr/docs/web-security/policies/content-security-policy/directives/script-src-elem). Utilisez `script-src-attr` pour appliquer une règle distincte, en général plus stricte, aux handlers inline.

Une politique minimale sûre pour cette directive, qui bloque tous les handlers inline:

```http
Content-Security-Policy: script-src-attr 'none'
```

## Chaîne de repli [#chaîne-de-repli]

`script-src-attr` se replie sur [`script-src`](/fr/docs/web-security/policies/content-security-policy/directives/script-src), puis sur [`default-src`](/fr/docs/web-security/policies/content-security-policy/directives/default-src). Si vous ne définissez pas `script-src-attr`, les handlers inline sont vérifiés contre `script-src`, et si elle est absente, contre `default-src`. Définir `script-src-attr` remplace `script-src` pour les attributs de handler uniquement.

La plupart des politiques n'ont pas besoin de `script-src-attr`, car `script-src` couvre déjà les handlers. La raison habituelle de la définir est d'interdire complètement les handlers inline avec `'none'` tout en autorisant encore des éléments script via `script-src`.

## Valeurs [#valeurs]

`script-src-attr` accepte les mêmes types de valeurs que `script-src`, mais seules quelques-unes peuvent correspondre à un handler inline.

| Valeur            | Statut   | Description                                                                                                   |
| ----------------- | -------- | ------------------------------------------------------------------------------------------------------------- |
| `'none'`          | ✅ Bon    | Bloque tous les event handlers inline. S'utilise seule.                                                       |
| `'sha256-...'`    | ✅ Bon    | Empreinte du texte exact du handler; ne correspond qu'avec `'unsafe-hashes'`.                                 |
| `'unsafe-hashes'` | ❌ Risqué | Permet aux hashes de correspondre aux attributs de handler; rouvre cette surface, à réserver à une migration. |
| `'report-sample'` | ✅ Bon    | Ajoute les 40 premiers caractères du handler bloqué aux reports.                                              |
| `'unsafe-inline'` | ❌ Risqué | Autorise tous les handlers inline, y compris injectés.                                                        |

La grammaire accepte aussi `'self'` et des sources host, scheme et nonce, mais un handler inline n'a pas d'URL à laquelle les faire correspondre. En pratique, `script-src-attr` s'utilise avec un petit ensemble de valeurs:

* `'none'` pour bloquer tous les event handlers inline.
* `'unsafe-inline'` pour tous les autoriser (déconseillé).
* Un [hash](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce) accompagné du mot-clé [`'unsafe-hashes'`](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords), qui est ce qui permet à un hash de correspondre à un handler inline.

Un nonce ne peut pas marquer un attribut, donc les handlers sont autorisés par `'unsafe-inline'` ou par un hash plus `'unsafe-hashes'`, pas par un nonce.

## Exemples [#exemples]

Bloquer tous les event handlers inline tout en laissant les éléments script se charger normalement:

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

## Usage courant [#usage-courant]

La configuration la plus propre est `script-src-attr 'none'`, qui force tout le comportement dans des fichiers de script marqués d'un nonce et correspond au schéma de la CSP stricte, voir le [guide strict-dynamic](/fr/blog/strict-dynamic-csp) et [comment script-src-elem et script-src-attr se répartissent script-src](/fr/blog/script-src-elem-vs-script-src-attr). Si vous ne pouvez pas retirer un handler hérité immédiatement, hachez-le et ajoutez `'unsafe-hashes'`, puis prévoyez de migrer le handler dans un fichier de script. Le [générateur de hash](/tools/csp-hash) calcule l'empreinte, et l'[évaluateur CSP](/tools/csp-evaluator) signale les règles de handler faibles.

## Notes de sécurité [#notes-de-sécurité]

Les event handlers inline sont un point d'entrée XSS fréquent, un `onclick` injecté exécute du code dans le contexte de la page. `script-src-attr 'none'` supprime entièrement ce point d'entrée.

* `'unsafe-inline'` autorise tous les handlers, y compris injectés, donc il annule la protection. Voir [pourquoi abandonner unsafe-inline](/fr/blog/unsafe-inline-csp).
* `'unsafe-hashes'` ne fait qu'élargir la correspondance des hashes aux handlers et aux attributs `style=`. Il n'autorise pas à lui seul les URL `javascript:` ni des blocs `<script>` inline entiers.

## Contournements et risques connus [#contournements-et-risques-connus]

Le risque principal est de laisser les handlers ouverts par accident. Si `script-src-attr` n'est pas définie et que `script-src` (ou `default-src`) porte `'unsafe-inline'`, tous les handlers inline s'exécutent, même avec une règle serrée sur les éléments script. Définissez `script-src-attr 'none'` pour fermer cette brèche.

`'unsafe-hashes'` est un assouplissement contrôlé, mais chaque handler haché est une chaîne figée. Le moindre changement du texte du handler casse le hash, et la tentation est de retomber sur `'unsafe-inline'`, qui rouvre le point d'entrée. Traitez les handlers hachés comme une étape de migration, pas comme une destination.

## Recommandation [#recommandation]

Déployez la politique stricte à base de nonce et rendez l'interdiction des handlers explicite:

```http
Content-Security-Policy:
    script-src 'nonce-{RANDOM}' 'strict-dynamic';
    script-src-attr 'none';
    object-src 'none';
    base-uri 'none'
```

La CSP stricte que recommandent la [cheat sheet CSP d'OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) et [web.dev](https://web.dev/articles/strict-csp) bloque déjà les handlers inline, puisque rien n'y les autorise. Ajouter `script-src-attr 'none'` exprime cette intention directement et garde les handlers bloqués même si `script-src` est assouplie plus tard. Déplacez le code des handlers dans des fichiers de script marqués d'un nonce.

## Reporting [#reporting]

Un handler inline bloqué produit un [report csp-violation](/fr/docs/web-security/reporting-api/reports/csp-violation) avec `script-src-attr` comme directive effective. Ajoutez `'report-sample'` pour inclure un court extrait du handler afin de le localiser. CentralCSP agrège ces reports pour que vous puissiez trouver et retirer les handlers inline avant de resserrer la directive.

## Prise en charge par les navigateurs [#prise-en-charge-par-les-navigateurs]

Largement prise en charge par les navigateurs actuels.

## Voir aussi [#voir-aussi]

* [script-src](/fr/docs/web-security/policies/content-security-policy/directives/script-src)
* [script-src-elem](/fr/docs/web-security/policies/content-security-policy/directives/script-src-elem)
* [default-src](/fr/docs/web-security/policies/content-security-policy/directives/default-src)
* [Valeurs mots-clés CSP](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords)
* [Générateur de hash](/tools/csp-hash)

## Sources [#sources]

* [MDN, CSP script-src-attr](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/script-src-attr)
* [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)
* [web.dev, Mitigate XSS with a strict CSP](https://web.dev/articles/strict-csp)
* [OWASP, Content Security Policy cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html)