# Source de schéma (/fr/docs/web-security/policies/content-security-policy/values/csp-scheme-source) Une source de schéma autorise toute ressource qui utilise un schéma d'URL donné, écrit comme le nom du schéma suivi de deux-points, par exemple `https:`, `data:` ou `blob:`. Elle est plus large qu'une [source d'hôte](/fr/docs/web-security/policies/content-security-policy/values/csp-host-source) : au lieu de nommer une origine, elle fait confiance à toute une classe d'URL. Cette ampleur rend une source de schéma pratique pour certains types de ressources et dangereuse pour d'autres. Une source de schéma est sûre pour du contenu affiché comme les images et les polices, jamais pour du script : ```http Content-Security-Policy: img-src 'self' data: ``` ## Syntaxe [#syntaxe] Une source de schéma est un nom de schéma plus deux-points, sans hôte ni chemin. Les schémas que vous rencontrez dans une CSP : | Schéma | Statut | Autorise | | -------------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------- | | `https:` | ✅ Bon | Toute ressource servie en HTTPS, depuis n'importe quel hôte. Très large ; préférez des hôtes explicites quand vous le pouvez. | | `http:` | ❌ Risqué | Toute ressource en HTTP simple, depuis n'importe quel hôte (il correspond aussi aux URL `https:`). | | `data:` | ❌ Risqué | Les URL `data:` inline. Dangereux dans `script-src`, `style-src` et `object-src` ; acceptable dans `img-src` et `font-src`. | | `blob:` | ❌ Risqué | Les URL `blob:` créées avec `URL.createObjectURL()`. Dangereux dans les contextes de script et de worker. | | `ws:` / `wss:` | ✅ Bon | Les endpoints WebSocket sur `connect-src` (`ws:` correspond aussi à `wss:`). | | `mediastream:` | ✅ Bon | Les URL `mediastream:` issues d'un périphérique de capture. De niche, `media-src` uniquement. | | `filesystem:` | ⚠️ Déprécié | Les URL `filesystem:` de l'ancienne API Filesystem de Chromium, de fait obsolète. | Un wildcard `*` nu n'est pas la même chose qu'une source de schéma : `*` couvre `http:` et `https:` et n'importe quel hôte, mais exclut délibérément `data:`, `blob:` et `filesystem:`, qui doivent donc être nommés explicitement même à côté de `*`. ## Ce à quoi elle correspond [#ce-à-quoi-elle-correspond] Une source de schéma correspond à toute URL utilisant ce schéma, quel que soit l'hôte, le port ou le chemin. `https:` dans `connect-src` autorise un `fetch()` vers n'importe quel endpoint HTTPS où qu'il soit. `data:` dans `img-src` autorise n'importe quelle image inline encodée en URL `data:`. ```http Content-Security-Policy: font-src 'self' data: ``` Cela laisse la page charger des polices auto-hébergées plus toute police embarquée en URL `data:`, ce qui est courant quand un fichier CSS inline une petite police. ## Pourquoi data: et blob: sont dangereux dans script-src et style-src [#pourquoi-data-et-blob-sont-dangereux-dans-script-src-et-style-src] Une URL `data:` ou `blob:` transporte son propre contenu, donc l'autoriser dans [`script-src`](/fr/docs/web-security/policies/content-security-policy/directives/script-src) revient à laisser du script s'exécuter depuis une chaîne construite par la page, ce qui est précisément le comportement que CSP existe pour empêcher. Un attaquant capable d'influencer une URL `data:`, ou qui injecte du balisage qui en construit une, peut exécuter du code arbitraire alors que la politique semble en vigueur. La même chose vaut pour [`style-src`](/fr/docs/web-security/policies/content-security-policy/directives/style-src) : une feuille de style `data:` peut transporter du CSS injecté. Gardez `data:` et `blob:` hors de `script-src` et `style-src`, et utilisez un [nonce ou un hash](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce) pour le code inline auquel vous faites vraiment confiance. ## Où les sources de schéma sont sûres [#où-les-sources-de-schéma-sont-sûres] Pour les types de ressources non exécutables, une source de schéma est un choix raisonnable et courant. `data:` dans [`img-src`](/fr/docs/web-security/policies/content-security-policy/directives/img-src) et [`font-src`](/fr/docs/web-security/policies/content-security-policy/directives/font-src) prend en charge les images inline et les polices embarquées avec peu de risque, parce que ces octets sont affichés, pas exécutés. `blob:` est souvent nécessaire dans `img-src` ou `media-src` pour les object URL que la page génère. La règle simple : une source de schéma convient pour des données que vous affichez et présente un risque pour du code que vous exécutez. ## Valeurs non sûres à éviter [#valeurs-non-sûres-à-éviter] `data:` ou `blob:` dans `script-src` ou `style-src` est la valeur à éviter ; elle rouvre le chemin du code inline qu'une politique est censée fermer. `https:` dans `script-src` est également faible, parce qu'il fait confiance au script de chaque hôte HTTPS du web, ce qui est à peine plus étroit que d'autoriser n'importe quel script. Préférez [`'strict-dynamic'`](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords) avec un nonce plutôt qu'une source de schéma pour le script. ## Contre quoi cela protège [#contre-quoi-cela-protège] Utilisées correctement, les sources de schéma vous laissent permettre une classe d'URL nécessaire (images inline, blobs générés) sans nommer chaque hôte, tout en gardant verrouillées les directives exécutables. Vérifiez qu'une politique n'a pas laissé `data:` ou `blob:` entrer dans une directive de script avec l'[évaluateur CSP](/tools/csp-evaluator). ## Contournements et limites connus [#contournements-et-limites-connus] Une source de schéma est grossière par conception : elle ne peut pas distinguer un hôte de confiance d'un hôte hostile au sein du même schéma, donc `https:` dans `connect-src` autorise l'exfiltration vers n'importe quel endpoint HTTPS. Quand une directive n'a besoin que de quelques origines, préférez les sources d'hôte. L'exclusion de `data:` et `blob:` du `*` est facile à oublier et mène à des images cassées jusqu'à ce que le schéma soit ajouté explicitement. ## Risques [#risques] Le risque principal est de dégainer une source de schéma comme correctif rapide quand une requête est bloquée, et d'élargir une directive de script ou de connexion bien plus que prévu. Ajoutez la source la plus étroite qui débloque la ressource, testez-la en [mode Report-Only](/fr/docs/web-security/policies/content-security-policy/report-only), et gardez `data:`/`blob:` hors des directives exécutables. ## Recommandation [#recommandation] Utilisez les sources de schéma uniquement pour du contenu affiché, et gardez la confiance des scripts sur un [nonce ou un hash](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce) avec `'strict-dynamic'`. ```http Content-Security-Policy: script-src 'nonce-{RANDOM}' 'strict-dynamic'; img-src 'self' data:; font-src 'self' data:; object-src 'none'; base-uri 'none' ``` La [cheat sheet CSP de l'OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) et le [guide de CSP stricte de web.dev](https://web.dev/articles/strict-csp) mettent tous deux en garde contre `data:`, `blob:` ou un schéma large dans une directive exécutable ; `data:` dans `img-src` et `font-src` est l'exception courante et acceptable. ## Exemples [#exemples] Autoriser les images inline et les polices embarquées, avec le script verrouillé sur un nonce : ```http Content-Security-Policy: default-src 'self'; img-src 'self' data:; font-src 'self' data:; script-src 'self' 'nonce-r4nd0m' ``` Autoriser les object URL générées pour les médias : ```http Content-Security-Policy: media-src 'self' blob: ``` ## Prise en charge par les navigateurs [#prise-en-charge-par-les-navigateurs] Les sources de schéma font partie du cœur de CSP et sont largement prises en charge par les navigateurs actuels. La règle du `*` qui exclut `data:`/`blob:`/`filesystem:` est cohérente d'un moteur à l'autre. ## Voir aussi [#voir-aussi] * [Source hôte](/fr/docs/web-security/policies/content-security-policy/values/csp-host-source) * [Mots-clés](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords) * [Directive img-src](/fr/docs/web-security/policies/content-security-policy/directives/img-src) * [Directive font-src](/fr/docs/web-security/policies/content-security-policy/directives/font-src) * [Directive script-src](/fr/docs/web-security/policies/content-security-policy/directives/script-src) ## Sources [#sources] * [W3C, Content Security Policy Level 3, scheme-source matching](https://w3c.github.io/webappsec-csp/#match-url-to-source-expression) * [MDN, CSP source values, scheme-source](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy) * [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)