default-src

La directive default-src est la liste de sources de repli de la plupart des directives de récupération (fetch) d'une politique de sécurité du contenu (Content Security Policy, CSP). Toute directive de récupération que vous ne définissez pas explicitement hérite des sources données à default-src, ce qui en fait le filet de sécurité qui décide de ce qui se charge quand une règle plus spécifique est absente.

Une politique minimale sûre pour cette directive:

Content-Security-Policy: default-src 'self'

Chaîne de repli

default-src n'a elle-même aucun repli. Elle est le bas de la chaîne: quand le navigateur vérifie une ressource, il cherche d'abord la directive la plus spécifique, et ne se replie sur default-src que si cette directive est absente de la politique.

Définir default-src 'self' ne signifie pas que chaque directive vaut désormais 'self'. Cela signifie que chaque directive de récupération que vous omettez se comporte comme 'self'. Dès que vous ajoutez une directive spécifique, par exemple script-src, celle-ci prend le relais pour les scripts et default-src ne s'applique plus à eux. Une erreur courante consiste à définir script-src et à supposer que les images sont encore couvertes: elles le sont, mais uniquement via default-src, donc vous devez garder default-src en place ou nommer img-src aussi.

Les directives que default-src couvre incluent script-src, style-src, img-src, font-src, connect-src, media-src, object-src, manifest-src et worker-src (via child-src).

Une récupération se résout par sa propre directive quand celle-ci est présente, et ne se replie sur default-src que quand elle est absente:

Les directives de document et de navigation ne participent pas à cette chaîne. base-uri, form-action, frame-ancestors, sandbox et les directives de reporting ne se replient jamais sur default-src: une directive non définie parmi celles-ci reste non définie.

Ce que default-src ne couvre pas

C'est le malentendu le plus courant en CSP. default-src n'est un repli que pour les directives de récupération. Elle ne couvre pas les directives de document et de navigation:

• base-uri
• form-action
• frame-ancestors
• sandbox
• Les directives de reporting report-uri et report-to

Si vous voulez restreindre où les formulaires envoient leurs données ou quels sites peuvent charger votre page dans une frame, vous devez définir ces directives vous-même. default-src 'self' ne fait rien pour elles. Laisser base-uri non définie, par exemple, reste un vrai vecteur de cross-site scripting (XSS) même avec un default-src strict.

Valeurs

default-src accepte une liste de sources séparées par des espaces, la même grammaire que toutes les directives de récupération. Comme elle sert de repli à ces directives, elle accepte tout ce que script-src accepte; les mots-clés propres aux scripts prennent effet quand le repli finit par régir une vérification de script.

Vous pouvez combiner:

• les sources mots-clés comme 'self' et 'none'
• une host source comme cdn.example.com ou *.example.com
• une scheme source comme https:
• une source nonce ou hash, même si elles n'ont de sens que pour les scripts et les styles

default-src 'none' bloque toutes les récupérations régies par la politique, une base stricte que vous rouvrez ensuite directive par directive.

Exemples

Content-Security-Policy:
  default-src 'self';
  img-src 'self' data:;
  object-src 'none'

Ici, les scripts, styles, polices, médias et connexions se replient tous sur 'self'. Les images autorisent en plus les URI data:, et le contenu de plugin est bloqué complètement. Tout ce qui n'est pas nommé hérite de 'self' via default-src.

Notes de sécurité

default-src 'self' est un plancher raisonnable, mais à elle seule cette valeur autorise encore les scripts inline de même origine chargés comme fichiers externes et ne fait rien pour les directives de document listées plus haut. Pour une politique forte, définissez default-src comme filet global, puis resserrez explicitement les directives à haut risque: un nonce ou un hash plus 'strict-dynamic' sur script-src, object-src 'none' et base-uri 'none'. Vous pouvez vérifier les lacunes d'un brouillon de politique avec l'évaluateur CSP avant de le déployer.

Évitez default-src * ou un scheme joker comme default-src https:, qui autorise le chargement depuis n'importe quel host et n'offre presque aucune protection. Un * nu ne correspond pas à data:, blob: ni filesystem:, donc un joker est à la fois trop large et discrètement incomplet.

Contournements et risques connus

Le vrai risque avec default-src est de trop lui faire confiance. Comme elle ne couvre pas base-uri, form-action, frame-ancestors ni sandbox, une politique réduite à default-src 'self' laisse ouverts le clickjacking, l'injection de balise base et l'exfiltration via form-action. Définissez ces directives directement.

Si vous comptez sur default-src pour couvrir les scripts mais que la page a besoin d'un script inline, vous ne pouvez pas assouplir les scripts sans tout assouplir, puisque default-src 'unsafe-inline' affaiblit chaque type de récupération. Ajoutez plutôt un script-src explicite, pour que l'assouplissement reste limité aux scripts.

Recommandation

Partez de default-src 'self' comme filet global, définissez explicitement les directives qui ne se replient jamais, et resserrez les scripts avec leur propre directive, au sein d'une politique de base complète:

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-endpoint

Associez-la à la déclaration d'endpoint dans un bloc séparé:

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

default-src 'self' couvre chaque récupération que vous n'avez pas nommée, tandis que base-uri, form-action et frame-ancestors sont définies directement parce que le repli ne les atteint jamais. La gestion des scripts passe à script-src, vous pouvez donc adopter un nonce sans assouplir le reste de la politique.

Reporting

Quand une requête est bloquée via le repli default-src, le navigateur envoie un report csp-violation nommant la directive effective qui a été vérifiée. Pointez la politique vers un endpoint de reporting pour collecter ces reports et voir quels types de récupération le repli intercepte avant de le resserrer.

Prise en charge par les navigateurs

default-src fait partie de CSP Level 1 et est prise en charge par tous les navigateurs qui implémentent CSP. Elle est stable et largement disponible.

FAQ

default-src couvre-t-elle toutes les directives ?

Non. default-src n'est un repli que pour les directives de récupération. Elle ne couvre pas base-uri, form-action, frame-ancestors, sandbox ni les directives de reporting, qui restent non définies sauf si vous les nommez explicitement. Un default-src 'self' strict ne fait rien pour elles, définissez-les donc vous-même.

default-src 'self' suffit-elle pour une CSP ?

Non. default-src 'self' est un plancher raisonnable, mais à elle seule elle autorise les scripts inline de même origine et ne fait rien pour les directives de document. Pour une politique forte, ajoutez un nonce ou un hash plus 'strict-dynamic' sur script-src, object-src 'none' et base-uri 'none'.

Voir aussi

• Directives de la Content Security Policy
• script-src
• base-uri
• Valeurs mots-clés CSP
• Suite CSP CentralCSP

Sources

• MDN, CSP default-src
• W3C, Content Security Policy Level 3
• W3C CSP editor's draft