object-src set to none
Why it matters
Flash, Java applets, and Silverlight plugins are extinct on the modern web but remain active attack vectors in browser contexts that don't block <object> and <embed> elements. Without object-src 'none', an injected <object> tag pointing to an attacker-controlled resource can execute plugin code with elevated privileges. CWE-693 (Protection Mechanism Failure) applies — the CSP is in place but fails to close a historically exploited resource category. OWASP A05 (Security Misconfiguration) flags unblocked plugin resources as a legacy misconfiguration that persists long after the actual plugin threat has been neutralized at the browser level.
Severity rationale
Low because modern browsers no longer support most plugins by default, but an explicit `object-src 'none'` is a zero-cost hardening step that eliminates a historically exploited attack surface.
Remediation
Add object-src 'none' explicitly to your CSP. No modern web application needs <object>, <embed>, or <applet> elements, so this directive should never require exceptions.
Content-Security-Policy: default-src 'none'; script-src 'nonce-{perRequest}' 'strict-dynamic'; object-src 'none'
Note: object-src does not fall back to default-src in all browsers — set it explicitly even when default-src 'none' is already configured. If your default-src is already 'none' and you verify object-src is not overridden elsewhere, you are covered, but explicit beats implicit for security-critical directives.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Security Headers II Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-693
- owasp:2021 · A05
Taxons
History
- 2026-04-18·v1.0.0·Initial import from security-headers-ii·automated