# img-src (/en/docs/web-security/policies/content-security-policy/directives/img-src)



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:

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

## Fallback chain [#fallback-chain]

`img-src` falls back to [`default-src`](/en/docs/web-security/policies/content-security-policy/directives/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 [#values]

`img-src` takes a space-separated source list combining [keyword sources](/en/docs/web-security/policies/content-security-policy/values/csp-keywords), [host sources](/en/docs/web-security/policies/content-security-policy/values/csp-host-source), and [scheme sources](/en/docs/web-security/policies/content-security-policy/values/csp-scheme-source):

| 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 [#examples]

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

This allows images from your own origin, inline `data:` URIs, and a named image host.

## Common use [#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`](/en/docs/web-security/policies/content-security-policy/directives/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 [#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](/tools/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 [#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 [#recommendation]

```http
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 [#reporting]

When an image is blocked, the browser sends a [csp-violation report](/en/docs/web-security/reporting-api/reports/csp-violation) 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 [#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.

## See also [#see-also]

* [Content Security Policy directives](/en/docs/web-security/policies/content-security-policy/introduction/csp-directives)
* [default-src](/en/docs/web-security/policies/content-security-policy/directives/default-src)
* [font-src](/en/docs/web-security/policies/content-security-policy/directives/font-src)
* [Scheme source values](/en/docs/web-security/policies/content-security-policy/values/csp-scheme-source)
* [CentralCSP CSP suite](/platform/csp-builder)

## Sources [#sources]

* [MDN, CSP img-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/img-src)
* [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)
* [W3C CSP editor's draft](https://w3c.github.io/webappsec-csp/)