You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great, if SecurityPolicyViolationEvents could be used to track down the exact element in the DOM that caused a CSP violation.
When adopting CSP the problem is often tying a particular violation to a given element on the page so the developer can change their templates/code to avoid it. What we currently have is heuristics to e.g. walk the DOM to see if there are any elements with inline event handlers, but this is a bit hacky and not guaranteed to work. Having a reference to the exact element would let us report the xpath, or do nice things on the client-side like highlighting the element. So it might turn out to be one of those tiny things that end up making CSP adoption quite a bit easier.
The text was updated successfully, but these errors were encountered:
It would be great, if SecurityPolicyViolationEvents could be used to track down the exact element in the DOM that caused a CSP violation.
When adopting CSP the problem is often tying a particular violation to a given element on the page so the developer can change their templates/code to avoid it. What we currently have is heuristics to e.g. walk the DOM to see if there are any elements with inline event handlers, but this is a bit hacky and not guaranteed to work. Having a reference to the exact element would let us report the xpath, or do nice things on the client-side like highlighting the element. So it might turn out to be one of those tiny things that end up making CSP adoption quite a bit easier.
The text was updated successfully, but these errors were encountered: