Skip to content

frame-src

frame-src specifies valid sources for <frame> and <iframe> - what your page may embed.

It is routinely confused with frame-ancestors, which controls who may embed your page. They point in opposite directions and neither substitutes for the other.

Content-Security-Policy: frame-src 'none';
Content-Security-Policy: frame-src <source-expression-list>;
  • <frame> and <iframe> document loads.

If frame-src is absent, the browser consults child-src, and then default-src. The full chain is frame-srcchild-srcdefault-src.

Content-Security-Policy: frame-src 'none'
  • Start at 'none' and add the embed origins you actually use - a video player, a payment iframe, a support widget. The list is short on most sites and the violations tell you what it should contain.
  • Add blob: only if you build iframe documents at runtime; it is not covered by 'self'.

Under frame-src https://www.youtube-nocookie.com:

<iframe src="https://www.youtube-nocookie.com/embed/VIDEO_ID"></iframe>

Under frame-src 'none':

<iframe src="https://support.vendor.example/widget"></iframe>
  • Widely available across browsers since August 2016.
  • The fallback runs frame-srcchild-srcdefault-src, so a policy with child-src but no frame-src still restricts iframes.
Field Value
violatedDirective frame-src
effectiveDirective frame-src
blockedUri https://support.vendor.example/widget
Issue title frame-src blocking support.vendor.example
  • The report comes from the embedding page, so documentUri is your page and blockedUri is the thing you tried to embed. A frame-ancestors violation is the mirror image and arrives from the embedded document instead.

Point your policy’s report-uri at your site’s HeaderHawk endpoint and the violations above arrive in the dashboard, grouped as described. The Quick Start sets that up in five minutes, and the integration guides cover the header syntax for each platform.