Source hôte
Comment une source hôte CSP correspond par schéma, hôte, wildcard, port et chemin, avec les pièges de correspondance qui surprennent.
Dernière mise à jour:
Une source d'hôte est le type de valeur le plus courant d'une politique de
sécurité du contenu (CSP) : un motif d'URL qui autorise des ressources provenant
d'une origine particulière, comme https://cdn.example.com ou *.example.com.
C'est ainsi que vous mettez en allowlist les tiers depuis lesquels une page peut
charger du script, des images, des polices ou des connexions. Les règles de
correspondance paraissent simples mais comportent des cas limites qui décident si
une vraie requête est autorisée, d'où l'importance des détails ci-dessous.
Une source d'hôte telle que vous la déploieriez, un CDN autorisé à côté de votre propre origine :
Content-Security-Policy: img-src 'self' https://cdn.example.comSyntaxe
Une source d'hôte est construite à partir de quatre parties, pour la plupart optionnelles : un schéma, un hôte, un port et un chemin.
Content-Security-Policy: script-src https://cdn.example.com:443/assets/La grammaire, lue de gauche à droite :
| Partie | Exemple | Signification |
|---|---|---|
| Schéma | https:// | Optionnel. S'il est omis, le schéma de la page est supposé, et une source http: correspond aussi à https:. |
| Hôte | cdn.example.com | Obligatoire. Un hôte complet, ou un wildcard *. en tête pour un niveau de sous-domaine. |
| Hôte wildcard | *.example.com | Correspond à un seul préfixe de sous-domaine, quel qu'il soit. |
| Port | :443 ou :* | Optionnel. Un port précis, ou :* pour n'importe quel port. S'il est omis, le port par défaut du schéma est utilisé. |
| Chemin | /assets/ | Optionnel. Restreint à un chemin ; un / final en fait une correspondance par préfixe. |
Les motifs que vous écrivez réellement se réduisent à quelques formes, et elles ne sont pas toutes aussi sûres.
| Motif | Statut | Description |
|---|---|---|
https://cdn.example.com | ✅ Bon | Un hôte précis en HTTPS, la forme la plus étroite d'allowlisting. |
*.example.com | ✅ Bon | N'importe quel sous-domaine de example.com, mais pas l'apex example.com lui-même. |
* | ❌ Risqué | N'importe quel hôte sur un schéma réseau. Dans script-src, il retire l'essentiel de la protection. |
Ce à quoi elle correspond
Une source d'hôte correspond à une URL de requête lorsque le schéma, l'hôte, le
port et le chemin concordent tous selon ces règles. La chaîne de requête et le
fragment ne font jamais partie de la correspondance, donc un ?v=2 ou un
#section sur une URL est ignoré.
Content-Security-Policy: img-src https://images.example.comCela autorise https://images.example.com/logo.png?cache=off et tout autre chemin
sur cet hôte exact, parce que la query est ignorée et qu'aucun chemin n'a été
spécifié.
Pièges de correspondance
Ces quatre comportements causent la plupart des surprises avec les sources d'hôte.
*.example.com ne correspond pas à example.com. Le wildcard représente une
étiquette de sous-domaine, donc *.example.com autorise cdn.example.com et
static.example.com mais pas l'apex nu example.com. Listez les deux si vous
avez aussi besoin de l'apex.
Content-Security-Policy: script-src *.example.com example.comUn * nu ne correspond pas à data:, blob: ni filesystem:. Le wildcard *
couvre les schémas réseau (http: et https:) et n'importe quel hôte, mais le
navigateur exclut délibérément les schémas data:, blob: et filesystem:. Si
une directive en a besoin, nommez la
source de schéma
explicitement, par exemple img-src * data:.
Un / final fait du chemin une correspondance par préfixe. Un chemin se terminant
par / correspond à ce chemin et à tout ce qui se trouve dessous. Un chemin sans
slash final doit correspondre exactement.
Content-Security-Policy: script-src https://cdn.example.com/lib/Cela autorise /lib/app.js et /lib/vendor/chart.js, mais /lib seul (sans
slash) n'autoriserait que cette URL exacte.
La query et le fragment sont ignorés. Deux URL qui ne diffèrent que par ?query
ou #fragment correspondent à la même source d'hôte, donc vous ne pouvez pas
autoriser ou bloquer une ressource selon sa chaîne de requête.
Valeurs non sûres à éviter
Une source d'hôte trop large affaiblit la politique. Un * nu dans script-src
autorise du script depuis n'importe quelle origine, ce qui retire l'essentiel de
la protection de CSP ; utilisez plutôt un nonce ou un hash. Un wildcard comme
*.googleapis.com ou https: dans script-src fait confiance à chaque hôte sous
ce schéma ou ce domaine, y compris ceux qu'un attaquant pourrait contrôler ou
détourner via une redirection ouverte. Préférez le
schéma strict-dynamic
plutôt que de maintenir une allowlist d'hôtes de script.
Contre quoi cela protège
Les sources d'hôte permettent à une politique de dire exactement quelles origines
peuvent servir chaque type de ressource, ce qui bloque un <script src> ou un
<img src> injecté pointant vers un domaine contrôlé par un attaquant. Limitez
chaque directive aux hôtes dont elle a réellement besoin, puis vérifiez le
résultat avec l'évaluateur CSP ou un
scan CSP.
Contournements et limites connus
Une allowlist d'hôtes n'est jamais plus étroite que son entrée la plus large.
Mettre en allowlist un hôte qui sert un endpoint JSONP, une redirection ouverte ou
un CDN public de bibliothèques arbitraires peut permettre à un attaquant de
charger du script exécutable via cette origine de confiance, raison pour laquelle
les politiques strictes évitent les allowlists d'hôtes de script au profit des
nonces et de 'strict-dynamic'. Les règles de wildcard ci-dessus impliquent aussi
qu'un *. mal jugé ou un apex manquant peut bloquer silencieusement une ressource
légitime.
Risques
Les deux modes d'échec tirent dans des directions opposées : une source d'hôte
trop large (un * nu, un schéma large, un CDN qui héberge n'importe quoi) et la
politique ne protège plus le script ; trop étroite (l'apex oublié, un port, un
besoin de data:) et des ressources réelles cassent. Testez les changements en
mode Report-Only
avant de les faire appliquer.
Recommandation
Pour le script, préférez un
nonce ou un hash
avec 'strict-dynamic' plutôt qu'une allowlist d'hôtes, et réservez les sources
d'hôte aux types de ressources qui ne font qu'afficher du contenu. Définissez
explicitement les directives restantes pour que rien ne se rabatte implicitement :
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-endpointReporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"La cheat sheet CSP de l'OWASP et le guide de CSP stricte de web.dev en font tous deux le choix par défaut, parce qu'une allowlist d'hôtes de script reste contournable via les endpoints JSONP et les redirections ouvertes des hôtes auxquels vous faisiez confiance, alors qu'un nonce ou un hash approuve chaque script individuellement.
Exemples
Autoriser votre propre origine plus un sous-domaine de CDN sur un chemin précis :
Content-Security-Policy: script-src 'self' https://cdn.example.com/js/Autoriser des images depuis n'importe quel sous-domaine d'un hôte, sur n'importe quel port :
Content-Security-Policy: img-src https://*.example.com:*Prise en charge par les navigateurs
La correspondance de source d'hôte fait partie du cœur de CSP et est largement prise en charge par les navigateurs actuels, y compris les règles de wildcard, de port et de préfixe de chemin décrites ici.
Voir aussi
Sources
Mots-clés
Référence des sources mot-clé CSP, self, none, unsafe-inline, unsafe-eval, strict-dynamic, unsafe-hashes, report-sample, et ce que chacune autorise.
Source de schéma
Comment fonctionnent les sources de schéma CSP comme https, data et blob, et pourquoi data et blob sont dangereux dans script-src mais sûrs dans img-src.