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 pour les éléments <script> et 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:

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

Chaîne de repli

script-src se replie sur 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

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

Elle accepte:

• Les sources mots-clés: '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 ('nonce-...', 'sha256-...') pour autoriser des scripts inline ou externes précis.
• Une host source comme https://cdn.example.com.
• Une 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

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

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

Usage courant

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

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 et le guide de mise en place des nonces.

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.
• '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, qui signale les valeurs faibles de script-src avant leur déploiement.

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

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:

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é:

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

C'est la CSP stricte que recommandent la cheat sheet CSP d'OWASP et web.dev, é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

Quand un script est bloqué, le navigateur envoie un report 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:

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

CentralCSP agrège ces reports et construit un inventaire de scripts 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

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

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 ?

'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 ?

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

• script-src-elem
• script-src-attr
• default-src
• Valeurs mots-clés CSP
• Nonces et hashes
• Évaluateur CSP

Sources

• MDN, CSP script-src
• W3C, Content Security Policy Level 3
• web.dev, Mitigate XSS with a strict CSP
• OWASP, Content Security Policy cheat sheet