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 via un élément <script>, que celui-ci 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 les balises <script> et les handlers doivent suivre des règles différentes.
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 script-src, plus large, couvre déjà les éléments script, la plupart des politiques n'ont jamais besoin de script-src-elem. Ne la définissez que si 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 ne correspond à un élément <script> que si celui-ci 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, un nonce se chargeant d'admettre 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. L'article 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 reste 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 vaut ici aussi : une redirection ouverte ou un endpoint JSONP sur une origine autorisée permet de charger du script arbitraire via un élément <script>. 'strict-dynamic' sort 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 piège plus discret consiste à 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= continuent de 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 par 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 si 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 s'appuie sur le hash reporting CSP pour construire un inventaire de scripts recensant chaque élément script de vos pages.
Prise en charge par les navigateurs
Largement prise en charge par les navigateurs actuels.