Attach first. The listener must exist before you dispatch.
Build the event.new SecurityPolicyViolationEvent(…) fills demo fields.
Dispatch on document. Same target MDN recommends for real CSP events.
Label it clearly. This teaches the API — a real violation still needs a CSP policy.
Compatibility
Browser Support
securitypolicyviolation is Baseline Widely available (MDN: since October 2018). Safe to use in modern evergreen browsers.
✓ Baseline · Widely available
securitypolicyviolation
Fires when a Content Security Policy is violated — listen on window or document.
99%Widely available
Google ChromeAll versions · Desktop & Mobile
Full support
Mozilla FirefoxAll versions · Desktop & Mobile
Full support
Apple SafariAll versions · macOS & iOS
Full support
Microsoft EdgeAll versions · Chromium & Legacy
Full support
Internet ExplorerIE 6+ · Legacy environments
Full support
OperaAll modern versions
Full support
securitypolicyviolationExcellent
Bottom line: Listen on window or document, log SecurityPolicyViolationEvent fields, and pair with a real CSP policy for production monitoring.
Frequently Asked Questions
It fires when a Content Security Policy (CSP) is violated—for example when a blocked script, image, or style is refused by the policy (MDN).
No. MDN marks Element securitypolicyviolation as Baseline Widely available (since October 2018). It is not Deprecated, Experimental, or Non-standard.
A SecurityPolicyViolationEvent, which inherits from Event. Useful properties include blockedURI, violatedDirective, effectiveDirective, originalPolicy, and disposition.
MDN recommends a top-level object such as Window or Document. In practice the event often targets document (for example a blocked image), rather than the HTML element.
Yes. It bubbles to the Window object and is composed, so top-level listeners can observe violations from the page.
A string indicating whether the user agent enforces the policy or only reports the violation (enforce vs report).