Skip to content
script-src.com
script-src.com
EN / FR

script-src-elem and script-src-attr

How the CSP Level 3 directives script-src-elem and script-src-attr split script control, and how they fall back to script-src.

CSP Level 3 splits script control into two narrower directives. script-src-elem governs <script> elements, and script-src-attr governs inline event handler attributes. Both fall back to script-src when unset, so most sites never need to set them directly.

script-src-elem

Applies to script elements: external <script src> and inline <script> blocks.

Content-Security-Policy: script-src-elem 'self' https://cdn.example.com

When present, it takes over element loading from script-src. This is useful when you want different rules for script elements than for event handlers, for example allowing a CDN for <script src> while blocking all inline handlers.

script-src-attr

Applies to inline event handler attributes such as onclick, onload, and onerror.

Content-Security-Policy: script-src-attr 'none'

script-src-attr 'none' blocks every inline event handler while leaving your <script> elements governed separately. A hash listed here, combined with 'unsafe-hashes', can allow specific handlers.

The fallback chain

For a given script, the browser picks the most specific directive that is set:

  1. script-src-elem or script-src-attr, depending on whether the script is an element or an attribute handler.
  2. script-src, if the specific directive is not set.
  3. default-src, if script-src is not set either.

So this policy blocks inline handlers but allows same-origin script elements, because script-src-attr is more specific for handlers:

Content-Security-Policy: script-src 'self'; script-src-attr 'none'

Should you use them?

Set script-src and you have covered both cases. Reach for the split directives only when you have a concrete reason to treat elements and attribute handlers differently. Keeping a single script-src is easier to audit.