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



La directive `script-src` d'une politique de sécurité du contenu (Content Security Policy, CSP) décide quels scripts une page est autorisée à charger et à exécuter. Elle régit les éléments `<script>`, les scripts inline et les event handlers, les URL `javascript:`, `eval()` et les évaluations dynamiques similaires, ainsi que les scripts exécutés par les workers. Si un script ne correspond pas à `script-src`, le navigateur refuse de l'exécuter. C'est la directive la plus importante pour arrêter le cross-site scripting (XSS).

`script-src` chapeaute deux directives plus fines, [`script-src-elem`](/fr/docs/web-security/policies/content-security-policy/directives/script-src-elem) pour les éléments `<script>` et [`script-src-attr`](/fr/docs/web-security/policies/content-security-policy/directives/script-src-attr) pour les attributs event handler inline. Quand vous les définissez, elles prennent en charge leur part du travail et `script-src` devient leur repli.

Une politique minimale sûre pour cette directive:

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

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

`script-src` se replie sur [`default-src`](/fr/docs/web-security/policies/content-security-policy/directives/default-src). Si vous définissez `default-src` et omettez `script-src`, les scripts sont vérifiés contre `default-src`. Si vous définissez `script-src`, elle remplace entièrement `default-src` pour les scripts.

Les directives plus fines se replient à travers `script-src`:

* `script-src-elem` se replie sur `script-src`, puis sur `default-src`.
* `script-src-attr` se replie sur `script-src`, puis sur `default-src`.

Un seul `script-src` couvre donc à la fois les éléments `<script>` et les handlers inline, sauf si vous surchargez l'un des deux.

## Valeurs [#valeurs]

`script-src` accepte une liste de sources séparées par des espaces, ou `'none'` pour bloquer tous les scripts.

| Valeur                                                    | Statut          | Description                                                                                                                                                         |
| --------------------------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `'none'`                                                  | ✅ Bon           | Bloque tous les scripts. S'utilise seule.                                                                                                                           |
| `'self'`                                                  | ✅ Bon           | Scripts de votre propre origine uniquement.                                                                                                                         |
| Host source                                               | ✅ Bon           | Un host précis comme `https://cdn.example.com`.                                                                                                                     |
| `https:`                                                  | ❌ Risqué        | N'importe quelle origine HTTPS peut servir du script, presque aucune liste d'autorisation.                                                                          |
| `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           | Jeton aléatoire par réponse, unique et impossible à deviner.                                                                                                        |
| `'sha256-...'`                                            | ✅ Bon           | Empreinte d'un bloc inline exact ou d'un fichier externe.                                                                                                           |
| `'strict-dynamic'`                                        | ✅ Bon           | La confiance découle des scripts autorisés par nonce ou hash; les sources host et scheme sont ignorées.                                                             |
| `'wasm-unsafe-eval'`                                      | ✅ Bon           | Compilation WebAssembly uniquement, plus étroit que `'unsafe-eval'`.                                                                                                |
| `'report-sample'`                                         | ✅ Bon           | Ajoute les 40 premiers caractères du code inline bloqué aux reports.                                                                                                |
| `'trusted-types-eval'`                                    | ✅ Bon           | N'autorise eval qu'avec TrustedScript quand les Trusted Types sont appliqués. Récemment devenu disponible dans les versions actuelles de Chrome, Firefox et Safari. |
| `'unsafe-inline'`                                         | ❌ Risqué        | Autorise tous les scripts inline, y compris injectés.                                                                                                               |
| `'unsafe-eval'`                                           | ❌ Risqué        | Autorise `eval()`, `new Function()` et les timers à base de chaînes.                                                                                                |
| `'unsafe-hashes'`                                         | ❌ Risqué        | Permet aux hashes de correspondre aux event handlers inline, rouvrant cette surface.                                                                                |
| `'inline-speculation-rules'`                              | 🧪 Expérimental | Scripts inline de speculation rules. Porté par Chromium, hors piste de standardisation.                                                                             |
| `'report-sha256'` / `'report-sha384'` / `'report-sha512'` | 🧪 Expérimental | [Collecte de hashes en report-only](/fr/docs/web-security/policies/content-security-policy/values/report-sha-keyword). Chromium uniquement.                         |

Elle accepte:

* Les [sources mots-clés](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords): `'self'`, `'none'`, `'unsafe-inline'`, `'unsafe-eval'`, `'wasm-unsafe-eval'`, `'strict-dynamic'`, `'unsafe-hashes'`, `'report-sample'`, `'trusted-types-eval'` et `'inline-speculation-rules'`.
* Un [nonce ou un hash](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce) (`'nonce-...'`, `'sha256-...'`) pour autoriser des scripts 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:`.

Deux interactions méritent d'être connues d'emblée. Ajouter un nonce ou un hash fait ignorer `'unsafe-inline'`, si bien que les navigateurs plus anciens qui ne comprennent pas les nonces conservent quand même la restriction sur l'inline. Ajouter `'strict-dynamic'` fait ignorer les entrées host et scheme de la liste: la confiance vient alors d'un nonce ou d'un hash.

## Exemples [#exemples]

Une politique à base de nonce qui autorise les scripts de même origine et un script inline marqué du nonce correspondant:

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

## Usage courant [#usage-courant]

La plupart des pages commencent par autoriser leur propre origine et un petit ensemble de hosts de confiance:

```http
Content-Security-Policy:
    script-src 'self' https://cdn.example.com;
    object-src 'none';
    base-uri 'none'
```

La recommandation moderne est une CSP stricte construite sur un nonce ou un hash plus `'strict-dynamic'`, plutôt qu'une liste de hosts autorisés. Une liste de hosts est facile à contourner via une redirection ouverte ou un endpoint JSONP sur un domaine autorisé, alors qu'une politique à base de nonce ne fait confiance qu'aux scripts que vous marquez explicitement. Voir le guide sur [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` est le contrôle central contre le XSS. Un `<script>` injecté ou un handler inline ne s'exécute que s'il correspond à la directive, donc un `script-src` serré transforme une injection en violation bloquée et rapportée au lieu d'une exécution de code.

* `'unsafe-inline'` annule l'essentiel de la protection: il autorise tout script inline, y compris injecté. Retirez-le et passez à un nonce ou un hash. Voir [pourquoi abandonner unsafe-inline](/fr/blog/unsafe-inline-csp).
* `'unsafe-eval'` autorise `eval()`, `new Function()` et `setTimeout` avec une chaîne. Évitez-le quand vous le pouvez; beaucoup de bibliothèques n'en ont plus besoin.
* `'wasm-unsafe-eval'` est l'alternative étroite qui n'autorise que la compilation WebAssembly, sans réactiver `eval()` de manière générale.

Vous pouvez valider une politique rapidement avec l'[évaluateur CSP](/tools/csp-evaluator), qui signale les valeurs faibles de `script-src` avant leur déploiement.

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

La liste de hosts autorisés est le point faible classique. Si une origine autorisée héberge un callback JSONP, une redirection ouverte ou une copie d'un framework permissif, un attaquant peut charger du script à travers elle. `'strict-dynamic'` contourne ce problème en ignorant la liste et en ne faisant confiance qu'aux scripts autorisés par nonce ou hash et à ce qu'ils créent.

`'unsafe-hashes'` élargit la correspondance des hashes aux event handlers inline et est parfois nécessaire pour du balisage hérité, mais il assouplit la politique; préférez déplacer les handlers dans des fichiers de script marqués d'un nonce. Un joker comme `*` ou un scheme large comme `https:` autorise du script depuis presque n'importe où et doit être traité comme l'absence quasi totale de `script-src`.

## Recommandation [#recommandation]

Pour `script-src`, déployez une politique stricte à base de nonce plutôt qu'une liste de hosts autorisés, au sein d'une politique de base complète qui définit aussi les autres directives importantes:

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

Associez-la à la déclaration d'endpoint dans un bloc séparé:

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

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), étendue avec chaque directive sans repli pour ne rien laisser implicite. `'strict-dynamic'` rend les sources host et scheme sans effet: la confiance vient uniquement du nonce propre à chaque réponse et se propage aux scripts que votre code autorisé charge. Régénérez le nonce à chaque réponse et gardez `'unsafe-inline'` et `'unsafe-eval'` hors de la politique.

## Reporting [#reporting]

Quand un script est bloqué, le navigateur envoie un [report csp-violation](/fr/docs/web-security/reporting-api/reports/csp-violation) nommant `script-src` (ou la directive résolue `script-src-elem` / `script-src-attr`) comme directive effective. Ajoutez `'report-sample'` pour inclure un court extrait du code bloqué dans le report, ce qui aide à identifier le script fautif. Pointez votre politique vers un endpoint pour les collecter:

```http
Content-Security-Policy:
    script-src 'self' 'nonce-r4nd0m';
    report-to csp-endpoint
```

CentralCSP agrège ces reports et construit un [inventaire de scripts](/platform/supply-chain) de tout ce qui s'exécute sur vos pages, pour voir l'usage réel de `script-src` avant de resserrer la directive.

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

`script-src` et ses mots-clés principaux, dont `'strict-dynamic'`, `'unsafe-eval'` et `'unsafe-inline'`, sont largement pris en charge. `'wasm-unsafe-eval'` est largement pris en charge dans les navigateurs actuels. `'trusted-types-eval'` est récemment devenu disponible dans les versions actuelles de Chrome, Firefox et Safari. `'inline-speculation-rules'` est porté par Chromium, disponible dans Safari uniquement derrière un flag, et hors piste de standardisation. La famille `'report-sha256'` est propre à Chromium.

## FAQ [#faq]

### Faut-il utiliser un nonce ou un hash dans script-src ? [#faut-il-utiliser-un-nonce-ou-un-hash-dans-script-src-]

Utilisez un nonce pour les pages rendues côté serveur dont les scripts inline
changent à chaque réponse; le serveur pose un nouveau jeton aléatoire à chaque
réponse et marque chaque script de confiance avec lui. Utilisez un hash pour les
scripts inline statiques qui ne changent jamais. Les deux suppriment
`'unsafe-inline'`, si bien que les navigateurs plus anciens conservent la
restriction sur l'inline.

### Que fait strict-dynamic ? [#que-fait-strict-dynamic-]

`'strict-dynamic'` laisse la confiance découler d'un script que la politique
autorisait déjà via un nonce ou un hash vers tous les scripts que ce script
crée, si bien qu'un loader de confiance peut charger ses dépendances. En
contrepartie, les entrées host et scheme de la liste sont ignorées, ce qui
supprime les contournements par redirection ouverte et JSONP qu'une liste de
hosts comporte.

### script-src arrête-t-il tout le XSS ? [#script-src-arrête-t-il-tout-le-xss-]

Non. `script-src` est le contrôle central qui transforme un script injecté en
violation bloquée et rapportée au lieu d'une exécution de code, mais il n'est
pas complet à lui seul. Associez-le à `object-src 'none'` et `base-uri 'none'`
pour fermer les vecteurs des plugins et de la balise base, et ajoutez les
Trusted Types pour verrouiller les sinks du DOM.

## Voir aussi [#voir-aussi]

* [script-src-elem](/fr/docs/web-security/policies/content-security-policy/directives/script-src-elem)
* [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)
* [Valeurs mots-clés CSP](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords)
* [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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/script-src)
* [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)