How to secure object-src in Content Security Policy?

csp-object-src-weakglobal

The object-src directive controls which sources can serve content for object, embed, and applet elements. When missing from CSP, the browser falls back to default-src or permits all sources. When set to a wildcard, any origin can load plugin content. Both conditions allow attackers to embed Flash SWFs, Java applets, or other plugin-based payloads that execute outside normal script sandboxing. Setting object-src to ‘none’ eliminates this class of attack with no practical cost on modern sites.

What’s wrong

The Content Security Policy either omits the object-src directive entirely or sets it to a wildcard (*). Without an explicit object-src, the browser applies default-src as a fallback. If default-src is also permissive, object, embed, and applet elements can load content from any origin. A wildcard object-src produces the same result explicitly. Either condition permits plugin-based content from untrusted sources to execute in the page context.

Why it matters

Plugin content runs outside the browser’s normal JavaScript sandbox. Flash and Java applets historically had their own execution environments with broader system access. An attacker who can inject an object or embed tag pointing to a malicious SWF or applet bypasses script-src restrictions entirely because plugin execution follows object-src, not script-src. Modern browsers have deprecated and removed most plugin support, but the object and embed elements remain valid HTML. A permissive object-src leaves the door open for any future plugin-like technology or for browsers that still support legacy plugins. The cost of setting object-src to ‘none’ is near zero on sites that do not embed Flash or Java content.

The correct change

Add object-src ‘none’ to the Content Security Policy header. This blocks all plugin and embed content regardless of source. If the site uses legitimate object or embed elements for PDF viewing or media, restrict object-src to the specific origins serving that content rather than allowing all. The end state is a policy where plugin-based execution paths are closed. No object, embed, or applet element can load content unless explicitly permitted from a named origin.

Scope

This condition applies globally. The object-src directive is set in the Content-Security-Policy HTTP header and governs all object, embed, and applet elements across the entire page. Individual elements cannot override the policy. Every page served with a permissive or missing object-src carries the same exposure.

How to verify

• Validation confirms the condition is resolved:
• • Content-Security-Policy header includes object-src directive
• • object-src is set to ‘none’ or restricted to specific trusted origins
• • No wildcard (*) in object-src value
• • Object and embed elements from untrusted sources fail to load
• • Browser console reports CSP violations when testing with injected object tags
• • Existing site functionality unaffected (no legitimate plugin dependencies broken)

Takeaway

• Plugin content executes outside the browser’s JavaScript sandbox and bypasses script-src
• Missing object-src falls back to default-src, which is often too permissive
• Wildcard object-src explicitly permits all origins to serve plugin content
• Setting object-src to ‘none’ has near-zero cost on modern sites that do not use Flash or Java

FAQ

Are plugins still a real threat if browsers have dropped Flash support?

Major browsers removed Flash support in 2021 and Java plugin support earlier. The direct Flash/Java attack surface is largely gone. However, object-src governs more than just legacy plugins. It controls embed and object elements that can load PDFs, SVGs, and other content types. Future plugin-like technologies would also fall under this directive. The security cost of leaving it open is real; the operational cost of closing it is negligible.

What is the difference between missing object-src and wildcard object-src?

Missing object-src causes the browser to fall back to default-src. If default-src is strict, missing object-src may still be safe in practice, but it relies on implicit behavior rather than explicit policy. Wildcard object-src (*) explicitly permits all origins. Both are violations because explicit restrictive policy is the standard. A missing directive is a gap; a wildcard is an intentional opening.

Does object-src ‘none’ break embedded PDFs?

If PDFs are loaded via object or embed tags, yes. The fix is to use iframe with appropriate frame-src permissions, or to set object-src to the specific origin serving the PDFs. Most modern PDF embedding uses iframe or direct links rather than object/embed elements. Audit existing pages for object and embed usage before deploying object-src ‘none’.

Why not just rely on default-src to cover object-src?

Default-src is a fallback, not a substitute for explicit directives. Relying on fallback behavior makes the policy harder to audit and easier to weaken accidentally. Changing default-src to accommodate one directive loosens restrictions for all uncovered directives simultaneously. Explicit object-src ‘none’ is immune to default-src changes.

Can object-src be deployed with report-only first?

Yes. Use Content-Security-Policy-Report-Only with the object-src directive to collect violation reports without enforcement. This reveals any legitimate object or embed usage that would break under the new policy. Once reports confirm no legitimate usage, transition to the enforcing header.

How does object-src interact with other CSP directives?

Object-src operates independently from script-src, style-src, and other fetch directives. Plugin content loaded via object-src does not need script-src permission to execute code because plugins run in their own execution context. This is exactly why object-src must be restricted separately. A strict script-src does not prevent plugin-based code execution.

The fix

Prevent plugin-based code execution by restricting object-src to ‘none’ or specific trusted origins

Done when: Content Security Policy includes object-src ‘none’ or object-src limited to explicitly trusted origins, blocking all unauthorized plugin and embed content

Do not

• Do not use wildcard (*) for object-src
• Do not omit object-src and rely on default-src fallback alone
• Do not add data: or blob: to object-src without understanding the risks
• Do not assume plugin deprecation eliminates the need for object-src restrictions

How to verify

• Content-Security-Policy header includes explicit object-src directive
• object-src value is ‘none’ or limited to specific trusted origins
• No wildcard in object-src
• Injected object and embed tags fail to load untrusted content
• No object-src-related CSP violations in production reports
• Legitimate embed functionality preserved if object-src allows specific origins

Find every page with this

probeo monitors this continuously across every page of your site, and records which pages passed, which failed, and which it could not determine.