CentralCSP
PolitiquesContent-Security-PolicyDirectives

img-src

La directive CSP img-src contrôle la provenance des images et des favicons, y compris les URI data dont les images inline ont souvent besoin.

Dernière mise à jour:

La directive img-src contrôle la provenance des images sous une politique de sécurité du contenu (Content Security Policy, CSP). Elle couvre les éléments <img>, les favicons, les images définies via CSS (comme background-image) et les requêtes d'image faites via le DOM ou l'API Fetch pour des destinations de type image.

Une politique minimale sûre pour cette directive:

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

Chaîne de repli

img-src se replie sur default-src. Si vous ne définissez pas img-src, les images sont régies par ce que default-src autorise. Si ni l'une ni l'autre n'est présente, les images se chargent depuis n'importe où.

Valeurs

img-src accepte une liste de sources séparées par des espaces combinant sources mots-clés, host sources et scheme sources:

ValeurStatutDescription
'none'✅ BonBloque tous les chargements d'images.
'self'✅ BonImages de l'origine de la page uniquement.
images.example.com✅ BonUn host d'images ou un CDN nommé.
https:✅ BonN'importe quelle origine HTTPS. Large; préférez des hosts nommés.
data:✅ BonURI data: inline. Une image ne peut pas s'exécuter, donc acceptable ici.
blob:✅ BonImages générées côté client (sortie de canvas, aperçus de fichiers).
*❌ RisquéN'importe quel host peut recevoir des requêtes d'images, un canal d'exfiltration. Ne correspond jamais à data: ni blob:.

Les nonces et les hashes ne s'appliquent pas aux images.

Exemples

Content-Security-Policy:
  default-src 'self';
  img-src 'self' data: https://images.example.com

Cela autorise les images depuis votre propre origine, les URI data: inline et un host d'images nommé.

Usage courant

Les images sont l'un des rares types de ressources où data: est en général raisonnable. Les SVG inline, les placeholders en base64, les sprites d'icônes et beaucoup de bibliothèques UI embarquent des images en URI data:, donc img-src (et font-src) ont souvent besoin de data: là où une directive de script ou de style ne devrait pas l'avoir. blob: est courant quand vous générez des images côté client, par exemple depuis un canvas ou l'aperçu d'un fichier téléversé.

Si votre favicon, votre image Open Graph ou un pixel de tracking analytics se charge depuis un autre host, ce host doit apparaître dans img-src (ou dans default-src), sinon la requête est bloquée.

Notes de sécurité

Les images sont un type de ressource à faible risque: une image bloquée dégrade la page mais la casse rarement, et une image ne peut pas s'exécuter. Cela fait de img-src un endroit sûr pour autoriser data: même quand votre politique globale est stricte. Passez un brouillon de politique dans l'évaluateur CSP pour confirmer que le reste de la politique reste serré.

Gardez en tête que les requêtes d'images font quand même fuiter de l'information. Un attaquant capable d'injecter une balise <img> peut utiliser un img-src permissif pour envoyer des données vers un host arbitraire via l'URL de l'image. Restreindre img-src à des hosts connus, plutôt que img-src * ou img-src https:, limite ce canal d'exfiltration.

Contournements et risques connus

Comme les images ne peuvent pas exécuter de code, la directive n'est pas un contrôle d'injection, c'est un contrôle d'exfiltration et d'intégrité du contenu. Le risque principal est une liste de sources trop large: img-src * ou un scheme nu permet à n'importe quel host de recevoir une requête d'image, un canal de données dissimulé pour une balise injectée. Un joker * ne correspond pas non plus à data: ni blob:, donc si vous en avez besoin, vous devez les lister explicitement même à côté de *.

Recommandation

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

Limitez img-src à votre propre origine plus les hosts d'images précis que vous utilisez. N'ajoutez data: que quand un framework ou un jeu d'icônes inline des images en URI data:; c'est acceptable pour les images parce qu'elles ne peuvent pas s'exécuter. Évitez * et les schemes nus, qui laissent le canal d'exfiltration par image ouvert.

Reporting

Quand une image est bloquée, le navigateur envoie un report csp-violation avec img-src comme effectiveDirective, incluant l'URL bloquée. CentralCSP collecte et agrège ces reports, pour que vous voyiez chaque host d'images que vos pages chargent réellement avant de resserrer la directive.

Prise en charge par les navigateurs

img-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.

Voir aussi

Sources

On this page