script-src-elem
La directive CSP script-src-elem contrôle les sources que les éléments script peuvent charger. Chaîne de repli, valeurs, exemples et risques.
Dernière mise à jour:
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. 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:
Content-Security-Policy: script-src-elem 'nonce-{RANDOM}' 'strict-dynamic'Chaîne de repli
script-src-elem se replie sur script-src, puis sur 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
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 comme
'self','unsafe-inline'et'strict-dynamic'. - Un nonce ou un hash pour autoriser des éléments script inline ou externes précis.
- Une host source comme
https://cdn.example.com. - Une 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
Autoriser les éléments script de même origine et un CDN, pendant qu'un nonce admet un bloc inline:
Content-Security-Policy: script-src-elem 'self' https://cdn.example.com 'nonce-r4nd0m'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; comment les deux directives se répartissent script-src 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 et le guide de mise en place des nonces.
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.- Calculez les hashes des blocs inline statiques avec le générateur de hash, et vérifiez la politique obtenue avec l'évaluateur CSP.
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.
Recommandation
Définissez la politique stricte à base de nonce sur script-src et laissez les éléments <script> en hériter via le repli:
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 et web.dev, 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
Un élément <script> bloqué produit un report 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 de chaque élément script sur vos pages.
Prise en charge par les navigateurs
Largement prise en charge par les navigateurs actuels.