img-src
The CSP img-src directive controls where images and favicons can load from, including data URIs that inline images often need.
Last update:
The img-src directive controls where images can load from under a Content Security Policy (CSP). It covers <img> elements, favicons, images set through CSS (such as background-image), and image requests made through the DOM or the Fetch API for image destinations.
A minimal safe policy for this directive:
Content-Security-Policy: img-src 'self'Fallback chain
img-src falls back to default-src. If you do not set img-src, images are governed by whatever default-src allows. If neither is present, images load from anywhere.
Values
img-src takes a space-separated source list combining keyword sources, host sources, and scheme sources:
| Value | Status | Description |
|---|---|---|
'none' | ✅ Good | Blocks all image loads. |
'self' | ✅ Good | Images from the page's own origin only. |
images.example.com | ✅ Good | A named image host or CDN. |
https: | ✅ Good | Any HTTPS origin. Broad; prefer named hosts. |
data: | ✅ Good | Inline data: URIs. Images cannot execute, so this is acceptable here. |
blob: | ✅ Good | Client-generated images (canvas output, file previews). |
* | ❌ Risky | Any host can receive image requests, an exfiltration channel. Never matches data: or blob:. |
Nonces and hashes do not apply to images.
Examples
Content-Security-Policy:
default-src 'self';
img-src 'self' data: https://images.example.comThis allows images from your own origin, inline data: URIs, and a named image host.
Common use
Images are one of the few resource types where data: is usually reasonable. Inline SVGs, base64 placeholders, icon sprites, and many UI libraries embed images as data: URIs, so img-src (and font-src) often need data: where a script or style directive should not. blob: is common when you generate images client-side, for example from a canvas or an uploaded file preview.
If your favicon, Open Graph image, or analytics tracking pixel loads from another host, that host has to appear in img-src (or in default-src), or the request is blocked.
Security notes
Images are a low-risk resource type: a blocked image degrades the page but rarely breaks it, and an image cannot execute. That makes img-src a safe place to allow data: even when your overall policy is strict. Run a draft policy through the CSP evaluator to confirm the rest of the policy stays tight.
Be aware that image requests still leak information. An attacker who can inject an <img> tag can use a permissive img-src to send data to an arbitrary host through the image URL. Restricting img-src to known hosts, rather than img-src * or img-src https:, limits that exfiltration channel.
Known bypasses and risks
Because images cannot run code, the directive is not an injection control, it is an exfiltration and content-integrity control. The main risk is over-broad sources: img-src * or a bare scheme allows any host to receive an image request, which is a covert data channel for an injected tag. A wildcard * also does not match data: or blob:, so if you need those you must list them explicitly even alongside *.
Recommendation
Content-Security-Policy: img-src 'self'Keep img-src to your own origin plus the specific image hosts you use. Add data: only when a framework or icon set inlines images as data: URIs; that is acceptable for images because they cannot execute. Avoid * and bare schemes, which leave the image exfiltration channel open.
Reporting
When an image is blocked, the browser sends a csp-violation report with img-src as the effectiveDirective, including the blocked URL. CentralCSP collects and aggregates these reports, so you can see every image host your pages actually load before you tighten the directive.
Browser support
img-src is part of CSP Level 1 and is supported in every browser that implements CSP. It is stable and widely available.