La directive base-uri, bloquer les injections de balise base

La directive CSP base-uri restreint les URL autorisées dans le href de la balise base et ferme un vecteur XSS courant par injection de balise base.

La directive base-uri contrôle quelles URL peuvent apparaître dans l'élément <base href> d'un document. La balise <base> réécrit l'URL de base par rapport à laquelle chaque lien, script et formulaire relatif de la page se résout, donc un attaquant capable d'injecter une seule balise <base> peut silencieusement pointer toutes vos URL de script relatives vers un serveur qu'il contrôle. base-uri est la directive qui ferme cette porte.

La plupart des sites ne définissent jamais de balise <base>, donc verrouillez-la entièrement :

Content-Security-Policy: base-uri 'none'

Chaîne de repli

base-uri n'a pas de repli. default-src ne la couvre pas, donc si vous l'omettez de votre politique, il n'y a aucune restriction sur <base>, aussi stricte que soit le reste de votre CSP. Cela fait de son omission l'une des lacunes les plus courantes et les plus dangereuses dans une politique par ailleurs solide.

Valeurs

base-uri prend une liste de sources, la même grammaire de valeurs que les directives fetch, mais elle n'accepte ni nonces ni hashes (ceux-ci décrivent du contenu, pas une URL de base).

Valeur	Statut	Description
`'none'`	✅ Bon	Interdit à tout élément `<base>` de définir une URL de base. Le choix recommandé pour la plupart des sites.
`'self'`	✅ Bon	Autorise un `<base href>` uniquement sur l'origine du document (schéma, hôte et port).
Source d'hôte ou de schéma	✅ Bon	Autorise un `<base href>` correspondant à cette source d'hôte ou source de schéma. Rarement nécessaire.

Si le href d'un élément <base> ne correspond pas à la liste de sources, le navigateur ignore cet élément et la page continue de résoudre les URL relatives par rapport à l'URL du document.

La plupart des sites n'ont pas du tout besoin de balise <base>, donc base-uri 'none' est le bon défaut. N'utilisez 'self' que si votre application définit réellement une URL de base same-origin. N'utilisez pas de joker ni de schéma large comme https: : une valeur permissive annule l'intérêt de la directive, car elle laisse une balise <base> injectée rediriger les URL relatives vers n'importe quel hôte de ce schéma.

Exemples

Verrouiller complètement <base> pour une politique stricte typique :

Content-Security-Policy:
    script-src 'nonce-r4nd0m' 'strict-dynamic';
    object-src 'none';
    base-uri 'none'

N'autoriser qu'une URL de base same-origin quand votre application en définit une :

Content-Security-Policy: base-uri 'self'

Notes de sécurité

base-uri bloque l'injection de balise base, une escalade de cross-site scripting (XSS) qui transforme une seule balise injectée en contrôle sur de nombreuses ressources à la fois. Considérez une page qui charge ses scripts avec des chemins relatifs :

<script src="/js/app.js"></script>

Si un attaquant injecte <base href="https://evil.example/"> plus tôt dans le document, le navigateur résout /js/app.js par rapport à l'origine de l'attaquant et charge son code à la place. Votre liste d'autorisation script-src peut toujours s'appliquer, mais une liste basée sur les hôtes qui fait confiance à l'origine du document peut être contournée, et même une politique à base de nonces peut être fragilisée quand les URL relatives se déplacent. Définir base-uri 'none' supprime entièrement le levier <base>.

Contournements et risques connus

base-uri ne régit que l'élément <base>. Elle n'arrête pas un attaquant qui peut injecter directement une URL de script complète, c'est le rôle de script-src. Traitez base-uri comme une couche d'une politique stricte, pas comme un contrôle autonome.

Le plus grand risque est l'omission, pas la mauvaise configuration. Une politique avec un script-src solide mais sans base-uri porte toujours la faille d'injection de balise base, et l'erreur est facile à commettre parce que rien d'autre dans la politique ne la signale. Passez votre politique dans l'évaluateur CSP pour repérer un base-uri manquant avant la mise en production.

Recommandation

Content-Security-Policy: base-uri 'none'

Déployez base-uri 'none' sauf si votre application définit un <base> same-origin, auquel cas utilisez 'self'. La cheat sheet CSP de l'OWASP comme les recommandations strict CSP de web.dev incluent base-uri 'none' dans la politique stricte, à côté d'un script-src à base de nonces et de object-src 'none', parce que les trois ensemble ferment les principaux chemins d'escalade par injection de script.

Reporting

Quand la directive bloque un élément <base>, le navigateur émet un report csp-violation nommant base-uri comme directive effective. Configurez la livraison avec la directive report-to et le header Reporting-Endpoints.

Prise en charge par les navigateurs

base-uri fait partie de CSP niveau 2 et niveau 3 et est largement prise en charge par les navigateurs actuels.

FAQ

Contre quoi base-uri protège-t-elle ?

base-uri bloque l'injection de balise base, une escalade XSS où un <base href> injecté réécrit l'URL par rapport à laquelle chaque script et lien relatif se résout, les pointant en silence vers le serveur d'un attaquant. Définir base-uri 'none' supprime entièrement le levier <base>, même quand le reste de votre politique est strict.

Faut-il mettre base-uri à none ?

Oui pour la plupart des sites. Peu de pages définissent une balise <base>, donc base-uri 'none' est le bon défaut et interdit à tout élément <base> de définir une URL de base. Utilisez 'self' seulement si votre application définit vraiment une URL de base same-origin. Évitez un joker ou un scheme large comme https:.

base-uri