Five images vanished from a client’s site: the logo and four staff photos. Nothing was wrong with the files. Content Security Policy blocking images was the cause, and the policy belonged to the site itself.

A Content Security Policy Is a Guest List for Your Own Pages

Your site sends a security header with every page. That header lists the places the browser may load images, frames and scripts from. Anything not on the list gets refused. It exists to stop injected code, and OWASP calls a strong policy “a second layer of protection” against problems like cross-site scripting. It’s the same family of trouble behind a fake “verify you are human” screen.

The catch is that the list is literal. A host that isn’t written down gets blocked, even when it’s yours. Each directive covers one kind of content:

That table follows the Mozilla img-src and frame-src documentation.

Content Security Policy Blocking Images: Two Real Cases

A form that wouldn’t load. A membership form refused to show inside a page. The usual suspect is the form service refusing to be embedded, so I tested that first. The service framed fine elsewhere. The block was on the host site. Its frame-src list named the main domain but not the subdomain the portal lives on. Chrome refused the frame and showed a broken-document icon. Visitors saw that icon and nothing else.

Images that vanished. The five missing images were referenced by the bare domain. The policy only listed the www version. To the browser those are two different hosts, so it blocked the site’s own files as if a stranger had sent them. That’s Content Security Policy blocking images in its plainest form. Mozilla’s source syntax guide shows a wildcard such as *.example.com for subdomains, but a host you didn’t list stays blocked.

Neither failure announced itself. A blocked image looks like a missing file, much like a plugin error that ran on my own site for 19 days.

How to Tell It’s Your Policy and Not the Other Service

1. Open the page, right-click, choose Inspect, and click the Console tab. Reload. A blocked item leaves a red message that names the directive that refused it.
2. Test the other side. Load the same image or framed service somewhere else. If it works there, your site is the one blocking it.
3. Open the Network tab, click the page itself, and look in the response headers for Content-Security-Policy. If it’s there, you’ve found your suspect.

Fix the Directive, Don’t Turn the Policy Off

With Content Security Policy blocking images, switching the policy off brings them back. It also removes the protection against injected scripts, so don’t. Add the missing host to the directive that blocked it: img-src for images, frame-src for iframes. When a directive isn’t set, the browser falls back to child-src and then default-src, so the gap can hide in a rule you never read.

Finding where the header comes from can take longer than the fix. A security plugin, an SEO plugin, a rule in .htaccess (a server settings file) or a code snippet can each send one. Check all four.

Test the change safely first. As web.dev explains, in report-only mode the policy “won’t block resources yet, so nothing on your site breaks,” but you still see what would have been blocked. Mozilla documents that Content-Security-Policy-Report-Only header and says it can’t be set from a meta tag.

What to Remember

When something on your site goes blank and the other service checks out, look at your own security header before you blame the plugin. If you’d rather not dig through headers yourself, I’m happy to take a look.

Sources

• OWASP Content Security Policy Cheat Sheet
• MDN: img-src
• MDN: frame-src
• MDN: CSP source values
• MDN: Content-Security-Policy-Report-Only
• web.dev: Strict CSP