block-all-mixed-content
block-all-mixed-content blocked every mixed-content request on a secure page, including the “optionally blockable” kinds - images, video, audio - that browsers used to allow with a warning.
Browsers now upgrade those automatically, which is the behaviour the directive existed to force. It survives in old policies and old blog posts.
Syntax
Section titled “Syntax”Content-Security-Policy: block-all-mixed-content;What it controls
Section titled “What it controls”- Every
http://subresource request made by anhttps://document, including inside iframes - historically.
Fallback
Section titled “Fallback”block-all-mixed-content had no fallback and took no value. It is also inert whenever upgrade-insecure-requests is present, which is evaluated first.
Recommended value
Section titled “Recommended value”Content-Security-Policy: upgrade-insecure-requests- Write that instead. It fixes the page rather than breaking it, and it is what browsers now do by default for the content this directive targeted.
- If you want a hard block rather than an upgrade, put
https:on the specific directive -img-src https:- which is both narrower and still supported.
Examples
Section titled “Examples”Blocked
Section titled “Blocked”What it used to refuse on an HTTPS page:
<img src="http://cdn.example.com/logo.png" alt="" />Browser support
Section titled “Browser support”- Still parsed by browsers that shipped it, and harmless where it is ignored.
- Never remove it from a policy in the same change as adding
upgrade-insecure-requestsif you need to be able to attribute a behaviour change - but there is no reason to keep it once the newer directive is in place.
In a HeaderHawk report
Section titled “In a HeaderHawk report”| Field | Value |
|---|---|
violatedDirective |
block-all-mixed-content |
effectiveDirective |
block-all-mixed-content |
blockedUri |
http://cdn.example.com/logo.png |
| Issue title | block-all-mixed-content blocking cdn.example.com |
- HeaderHawk recognises the directive name, so historic reports group correctly.
- Any traffic here on a modern browser is a signal that the policy still carries the directive and that
upgrade-insecure-requestsis absent - otherwise it would have been inert.
Related directives
Section titled “Related directives”Getting reports for this directive
Section titled “Getting reports for this directive”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.