style-src
La directive CSP style-src contrôle quelles feuilles de style et quels styles inline une page peut appliquer. Valeurs, chaîne de repli et exemples.
Dernière mise à jour:
La directive style-src d'une politique de sécurité du contenu (Content Security Policy, CSP) décide quels styles une page est autorisée à appliquer. Elle couvre les feuilles de style externes chargées avec <link rel="stylesheet">, les blocs <style> inline, les attributs style= sur les éléments et les styles définis via le CSSOM. Si un style ne correspond pas à style-src, le navigateur refuse de l'appliquer.
style-src chapeaute deux directives plus fines, style-src-elem pour les feuilles de style et les blocs <style> et style-src-attr pour les attributs style= inline. Quand vous les définissez, elles prennent en charge leur part du travail.
Une politique minimale sûre pour cette directive:
Content-Security-Policy: style-src 'self' 'nonce-{RANDOM}'Chaîne de repli
style-src se replie sur default-src. Si vous définissez default-src et omettez style-src, les styles sont vérifiés contre default-src. Si vous définissez style-src, elle remplace entièrement default-src pour les styles.
Les directives plus fines se replient à travers style-src:
style-src-elemse replie surstyle-src, puis surdefault-src.style-src-attrse replie surstyle-src, puis surdefault-src.
Un seul style-src couvre donc les feuilles de style, les blocs <style> et les attributs style=, sauf si vous surchargez l'un d'eux.
Valeurs
style-src accepte une liste de sources séparées par des espaces, ou 'none'.
| Valeur | Statut | Description |
|---|---|---|
'none' | ✅ Bon | Bloque tous les styles. S'utilise seule. |
'self' | ✅ Bon | Styles de votre propre origine uniquement. |
| Host source | ✅ Bon | Un host précis comme https://fonts.example.com. |
https: | ✅ Bon | N'importe quelle origine en TLS. Très large pour des styles. |
data: | ❌ Risqué | Les URL data: peuvent transporter des styles contrôlés par un attaquant. |
blob: | ❌ Risqué | Les URL blob: peuvent transporter des styles contrôlés par un attaquant. |
'nonce-...' | ✅ Bon | Jeton aléatoire par réponse sur un élément <style> ou <link>. |
'sha256-...' | ✅ Bon | Empreinte d'un bloc <style> inline exact. |
'report-sample' | ✅ Bon | Ajoute les 40 premiers caractères des styles inline bloqués aux reports. |
'unsafe-hashes' | ❌ Risqué | Permet aux hashes de correspondre aux attributs style=, rouvrant cette surface. |
'unsafe-inline' | ❌ Risqué | Autorise tous les styles inline, y compris injectés. |
Elle accepte:
- Les sources mots-clés:
'self','none','unsafe-inline','unsafe-hashes'et'report-sample'. - Un nonce ou un hash pour autoriser un bloc
<style>ou une feuille de style précis. - Une host source comme
https://fonts.example.com. - Une scheme source comme
https:.
Comme pour les scripts, ajouter un nonce ou un hash fait ignorer 'unsafe-inline', donc une politique de style à base de nonce restreint toujours les styles inline sur les navigateurs qui ne comprennent pas les nonces. Contrairement à script-src, il n'existe ni 'strict-dynamic' ni 'unsafe-eval' pour les styles.
Exemples
Autoriser les styles de même origine et un bloc <style> inline via un nonce:
Content-Security-Policy: style-src 'self' 'nonce-r4nd0m'Usage courant
Beaucoup de sites ont besoin de 'self' plus un host de polices ou de composants, et soit un nonce sur leur <style> inline, soit des hashes pour les blocs statiques:
Content-Security-Policy:
style-src 'self' https://fonts.example.com 'nonce-r4nd0m'Le point de friction le plus courant est 'unsafe-inline'. Les bibliothèques UI et les frameworks injectent souvent des styles inline, ce qui pousse à garder 'unsafe-inline' sur style-src. Quand vous le pouvez, passez plutôt aux nonces ou aux hashes, voir le guide sur la suppression de unsafe-inline. L'évaluateur CSP montre si votre style-src en dépend encore.
Notes de sécurité
L'injection de style est moins grave que l'injection de script, mais elle est réelle. Du CSS contrôlé par un attaquant peut restyler une page à des fins de phishing, masquer ou recouvrir des éléments, et dans certains cas exfiltrer des données via des sélecteurs d'attribut et des requêtes background-image.
'unsafe-inline'autorise tout style inline, y compris injecté, et c'est la valeur à retirer. Un nonce ou un hash le remplace proprement pour les styles que vous contrôlez.'unsafe-hashes'n'est nécessaire que pour hacher des attributsstyle=inline (voirstyle-src-attr).
Contournements et risques connus
Une liste de hosts large ou un scheme comme https: autorise des feuilles de style depuis presque n'importe où, ce qui affaiblit la directive. L'exfiltration par CSS signifie qu'un style-src permissif n'est pas anodin, même si les styles n'exécutent pas de code. Gardez la liste de sources serrée et préférez les nonces ou les hashes à 'unsafe-inline'.
Recommandation
Autorisez vos propres feuilles de style et marquez d'un nonce ou d'un hash les styles inline que vous contrôlez, sans 'unsafe-inline':
Content-Security-Policy: style-src 'self' 'nonce-{RANDOM}'Une fois un nonce ou un hash présent, 'unsafe-inline' est de toute façon ignoré, donc il n'y a aucune raison de le garder. Hachez les blocs <style> statiques qui ne changent jamais, et limitez la liste de hosts aux origines que vous contrôlez.
Reporting
Un style bloqué produit un report csp-violation nommant style-src (ou la directive résolue style-src-elem / style-src-attr) comme directive effective. Ajoutez 'report-sample' pour inclure un court extrait du style bloqué. CentralCSP agrège ces reports pour que vous voyiez quels styles inline un style-src plus strict casserait avant de le déployer.
Prise en charge par les navigateurs
Largement prise en charge par les navigateurs actuels, y compris les nonces et les hashes pour les styles.