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



The `style-src` directive in a Content Security Policy (CSP) decides which styles a page is allowed to apply. It covers external stylesheets loaded with `<link rel="stylesheet">`, inline `<style>` blocks, `style=` attributes on elements, and styles set through the CSSOM. If a style does not match `style-src`, the browser refuses to apply it.

`style-src` is the umbrella for two finer directives, [`style-src-elem`](/en/docs/web-security/policies/content-security-policy/directives/style-src-elem) for stylesheets and `<style>` blocks and [`style-src-attr`](/en/docs/web-security/policies/content-security-policy/directives/style-src-attr) for inline `style=` attributes. When you set those, they take over their part of the job.

A minimal safe policy for this directive:

```http
Content-Security-Policy: style-src 'self' 'nonce-{RANDOM}'
```

## Fallback chain [#fallback-chain]

`style-src` falls back to [`default-src`](/en/docs/web-security/policies/content-security-policy/directives/default-src). If you set `default-src` and omit `style-src`, styles are checked against `default-src`. If you set `style-src`, it fully replaces `default-src` for styles.

The finer directives fall back through `style-src`:

* `style-src-elem` falls back to `style-src`, then `default-src`.
* `style-src-attr` falls back to `style-src`, then `default-src`.

A single `style-src` therefore covers stylesheets, `<style>` blocks, and `style=` attributes unless you override one of them.

## Values [#values]

`style-src` takes a space-separated source list, or `'none'`.

| Value             | Status  | Description                                                       |
| ----------------- | ------- | ----------------------------------------------------------------- |
| `'none'`          | ✅ Good  | Blocks every style. Used alone.                                   |
| `'self'`          | ✅ Good  | Styles from your own origin only.                                 |
| Host source       | ✅ Good  | A specific host such as `https://fonts.example.com`.              |
| `https:`          | ✅ Good  | Any origin over TLS. Very broad for styles.                       |
| `data:`           | ❌ Risky | `data:` URLs can carry attacker-controlled styles.                |
| `blob:`           | ❌ Risky | `blob:` URLs can carry attacker-controlled styles.                |
| `'nonce-...'`     | ✅ Good  | Per-response random token on a `<style>` or `<link>` element.     |
| `'sha256-...'`    | ✅ Good  | Digest of an exact inline `<style>` block.                        |
| `'report-sample'` | ✅ Good  | Adds the first 40 characters of blocked inline styles to reports. |
| `'unsafe-hashes'` | ❌ Risky | Lets hashes match `style=` attributes; re-enables that surface.   |
| `'unsafe-inline'` | ❌ Risky | Allows every inline style, including injected ones.               |

It accepts:

* [Keyword sources](/en/docs/web-security/policies/content-security-policy/values/csp-keywords): `'self'`, `'none'`, `'unsafe-inline'`, `'unsafe-hashes'`, and `'report-sample'`.
* A [nonce or hash](/en/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce) to allow a specific `<style>` block or stylesheet.
* A [host source](/en/docs/web-security/policies/content-security-policy/values/csp-host-source) such as `https://fonts.example.com`.
* A [scheme source](/en/docs/web-security/policies/content-security-policy/values/csp-scheme-source) such as `https:`.

As with scripts, adding a nonce or hash makes `'unsafe-inline'` ignored, so a nonce-based style policy still restricts inline styles on browsers that do not understand nonces. Unlike `script-src`, there is no `'strict-dynamic'` or `'unsafe-eval'` for styles.

## Examples [#examples]

Allow same-origin styles and one inline `<style>` block via a nonce:

```http
Content-Security-Policy: style-src 'self' 'nonce-r4nd0m'
```

## Common use [#common-use]

Many sites need `'self'` plus a font or component host, and either a nonce on their inline `<style>` or hashes for static blocks:

```http
Content-Security-Policy:
    style-src 'self' https://fonts.example.com 'nonce-r4nd0m'
```

The most common pain point is `'unsafe-inline'`. UI libraries and frameworks often inject inline styles, which pushes people to keep `'unsafe-inline'` on `style-src`. Where you can, move to nonces or hashes instead, see the how-to on [removing unsafe-inline](/en/blog/unsafe-inline-csp). The [CSP evaluator](/tools/csp-evaluator) shows whether your `style-src` still depends on it.

## Security notes [#security-notes]

Style injection is a lower-severity issue than script injection, but it is real. Attacker-controlled CSS can restyle a page for phishing, hide or overlay elements, and in some cases exfiltrate data through attribute selectors and background-image requests.

* `'unsafe-inline'` allows any inline style, including injected ones, and is the value to remove. A nonce or hash replaces it cleanly for the styles you control.
* `'unsafe-hashes'` is needed only to hash inline `style=` attributes (see [`style-src-attr`](/en/docs/web-security/policies/content-security-policy/directives/style-src-attr)).

## Known bypasses and risks [#known-bypasses-and-risks]

A broad host allowlist or a scheme like `https:` allows stylesheets from almost anywhere, which weakens the directive. CSS-based exfiltration means a permissive `style-src` is not harmless even though styles do not run code. Keep the source list tight and prefer nonces or hashes over `'unsafe-inline'`.

## Recommendation [#recommendation]

Allow your own stylesheets and nonce or hash the inline styles you control, without `'unsafe-inline'`:

```http
Content-Security-Policy: style-src 'self' 'nonce-{RANDOM}'
```

Once a nonce or hash is present, `'unsafe-inline'` is ignored anyway, so there is no reason to keep it. Hash static `<style>` blocks that never change, and keep the host list to origins you control.

## Reporting [#reporting]

A blocked style produces a [csp-violation report](/en/docs/web-security/reporting-api/reports/csp-violation) naming `style-src` (or the resolved `style-src-elem` / `style-src-attr`) as the effective directive. Add `'report-sample'` to include a short sample of the blocked style. CentralCSP aggregates these reports so you can see which inline styles a stricter `style-src` would break before you ship it.

## Browser support [#browser-support]

Widely supported across current browsers, including nonces and hashes for styles.

## See also [#see-also]

* [style-src-elem](/en/docs/web-security/policies/content-security-policy/directives/style-src-elem)
* [style-src-attr](/en/docs/web-security/policies/content-security-policy/directives/style-src-attr)
* [default-src](/en/docs/web-security/policies/content-security-policy/directives/default-src)
* [Nonces and hashes](/en/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce)
* [CSP evaluator](/tools/csp-evaluator)

## Sources [#sources]

* [MDN, CSP style-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/style-src)
* [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)
