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



La directive `script-src-elem` d'une politique de sécurité du contenu (Content Security Policy, CSP) contrôle quels scripts peuvent se charger à travers un élément `<script>`, que l'élément pointe vers un fichier externe ou contienne un bloc de script inline. Elle ne couvre pas les attributs event handler inline comme `onclick`, ceux-ci relèvent de [`script-src-attr`](/fr/docs/web-security/policies/content-security-policy/directives/script-src-attr). Utilisez `script-src-elem` quand vous voulez une règle différente pour les balises `<script>` et pour les handlers.

Une politique minimale sûre pour cette directive, à base de nonce plutôt que de liste de hosts:

```http
Content-Security-Policy: script-src-elem 'nonce-{RANDOM}' 'strict-dynamic'
```

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

`script-src-elem` 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-elem`, les éléments `<script>` sont vérifiés contre `script-src`, et si elle est aussi absente, contre `default-src`. Définir `script-src-elem` remplace entièrement `script-src` pour les éléments `<script>`.

Comme le `script-src` plus large couvre déjà les éléments script, la plupart des politiques n'ont jamais besoin de `script-src-elem`. Ne l'utilisez que quand les éléments script et les handlers inline doivent suivre des règles distinctes.

## Valeurs [#valeurs]

`script-src-elem` accepte les mêmes types de valeurs que `script-src`, ou `'none'`.

| Valeur             | Statut   | Description                                                                                              |
| ------------------ | -------- | -------------------------------------------------------------------------------------------------------- |
| `'none'`           | ✅ Bon    | Bloque tous les éléments `<script>`. S'utilise seule.                                                    |
| `'self'`           | ✅ Bon    | Éléments script de votre propre origine uniquement.                                                      |
| Host source        | ✅ Bon    | Un host précis comme `https://cdn.example.com`.                                                          |
| `https:`           | ✅ Bon    | N'importe quelle origine en TLS. Très large pour des scripts.                                            |
| `data:`            | ❌ Risqué | Des URL `data:` contrôlées par un attaquant s'exécutent comme script.                                    |
| `blob:`            | ❌ Risqué | Les URL `blob:` s'exécutent comme script, un vecteur XSS.                                                |
| `'nonce-...'`      | ✅ Bon    | Correspond à un élément `<script>` portant le même attribut `nonce`.                                     |
| `'sha256-...'`     | ✅ Bon    | Empreinte d'un bloc inline exact ou d'un fichier externe.                                                |
| `'strict-dynamic'` | ✅ Bon    | La confiance découle des éléments autorisés par nonce ou hash; les sources host et scheme sont ignorées. |
| `'report-sample'`  | ✅ Bon    | Ajoute les 40 premiers caractères du code inline bloqué aux reports.                                     |
| `'unsafe-inline'`  | ❌ Risqué | Autorise tout bloc `<script>` inline, y compris injecté.                                                 |

Elle accepte:

* Des [sources mots-clés](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords) comme `'self'`, `'unsafe-inline'` et `'strict-dynamic'`.
* Un [nonce ou un hash](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce) pour autoriser des éléments script inline ou externes précis.
* Une [host source](/fr/docs/web-security/policies/content-security-policy/values/csp-host-source) comme `https://cdn.example.com`.
* Une [scheme source](/fr/docs/web-security/policies/content-security-policy/values/csp-scheme-source) comme `https:`.

Les nonces et les hashes s'appliquent ici exactement comme sur `script-src`. Un nonce sur un élément `<script>` ne correspond que si l'élément porte le même attribut `nonce`, et un hash correspond au contenu textuel exact d'un bloc inline.

## Exemples [#exemples]

Autoriser les éléments script de même origine et un CDN, pendant qu'un nonce admet un bloc inline:

```http
Content-Security-Policy: script-src-elem 'self' https://cdn.example.com 'nonce-r4nd0m'
```

## Usage courant [#usage-courant]

Un usage typique consiste à autoriser vos propres scripts et un petit ensemble de hosts de confiance pour les éléments `<script>`, puis à contrôler les handlers séparément avec [`script-src-attr`](/fr/docs/web-security/policies/content-security-policy/directives/script-src-attr); [comment les deux directives se répartissent script-src](/fr/blog/script-src-elem-vs-script-src-attr) détaille cette séparation avec un exemple complet. Comme pour `script-src`, le schéma solide est un nonce ou un hash plus `'strict-dynamic'` plutôt qu'une liste de hosts, voir le [guide strict-dynamic](/fr/blog/strict-dynamic-csp) et le [guide de mise en place des nonces](/fr/blog/csp-nonce-setup).

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

`script-src-elem` bloque les balises `<script>` injectées qui ne correspondent pas à la liste de sources. Ajouter un nonce ou un hash fait ignorer `'unsafe-inline'`, ce qui est précisément ce qui empêche un attaquant d'injecter un bloc `<script>` inline.

* `'unsafe-inline'` autorise tout `<script>` inline, y compris injecté. Remplacez-le par un nonce ou un hash, voir [pourquoi abandonner unsafe-inline](/fr/blog/unsafe-inline-csp).
* Calculez les hashes des blocs inline statiques avec le [générateur de hash](/tools/csp-hash), et vérifiez la politique obtenue avec l'[évaluateur CSP](/tools/csp-evaluator).

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

La faiblesse des listes de hosts s'applique ici aussi: une redirection ouverte ou un endpoint JSONP sur une origine autorisée peut charger du script arbitraire via un élément `<script>`. `'strict-dynamic'` retire la liste de la décision et ne fait confiance qu'aux éléments autorisés par nonce ou hash et aux scripts qu'ils créent.

Un risque subtil est d'oublier que `script-src-elem` ne couvre pas les handlers. Si vous resserrez `script-src-elem` mais laissez `script-src` (ou `default-src`) permissive, les handlers inline `onclick=` peuvent encore s'exécuter, car ils se résolvent via [`script-src-attr`](/fr/docs/web-security/policies/content-security-policy/directives/script-src-attr).

## Recommandation [#recommandation]

Définissez la politique stricte à base de nonce sur `script-src` et laissez les éléments `<script>` en hériter via le repli:

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

C'est 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), et elle couvre les éléments script sans `script-src-elem` séparée. Ne définissez `script-src-elem` que quand les éléments et les handlers inline ont réellement besoin de règles différentes, et gardez-la à base de nonce ou de hash plutôt que de liste de hosts.

## Reporting [#reporting]

Un élément `<script>` bloqué produit un [report csp-violation](/fr/docs/web-security/reporting-api/reports/csp-violation) avec `script-src-elem` comme directive effective. Ajoutez `'report-sample'` pour inclure un court extrait du contenu bloqué. CentralCSP collecte ces reports et utilise le hash reporting CSP pour construire un [inventaire de scripts](/platform/supply-chain) de chaque élément script sur vos pages.

## 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-attr](/fr/docs/web-security/policies/content-security-policy/directives/script-src-attr)
* [default-src](/fr/docs/web-security/policies/content-security-policy/directives/default-src)
* [Nonces et hashes](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce)
* [Évaluateur CSP](/tools/csp-evaluator)

## Sources [#sources]

* [MDN, CSP script-src-elem](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/script-src-elem)
* [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)