Strict CSP Fallback Ineffective in Safari 14.1

[quoid]

macOS version: 11.3
Userscripts version: 3.1.0
Safari version: 14.1

Currently the content script listens for security policy violations, and when one occurs it attempts to discern if that policy violation came from the content script. It attempts to figure that out by the event.sourceFile, which under ideal circumstance would have a URI that begins with safari-extension.

That does not seem to be working any longer as in my dev tools I am seeing an empty string when the content script triggers a SecurityPolicyViolationEvent. This is happening across multiple sites that have strict CSPs.

This effectively makes the check that is being done worthless. Since event.sourceFile is an empty string, the expression will always evaluate to true; every SecurityPolicyViolationEvent will trigger a repeat injection of code.

As an alternative, I think checking the event's effectiveDirective, might be viable.

If event.effectiveDirective === "script-src" && event.sourceFile === "", it might be fair to assume the content script trigger ed the violation. Obviously, if/when Safari starts reporting the event.sourceFile properly from extensions again, this will break.

I wonder if there is a better implementation.

[quoid]

Another option is to simply check if event.effectiveDirective === "script-src".

If the event is triggered and the directive was due to a script, a "strict" CSP is present. The only current ways I can see that a content script won't be blocked by a CSP is if the webmaster did not include a CSP or the CSP for script-src is * - both of which wouldn't have triggered the policy event with an effectiveDirective of script-src.

The event.originalPolicy can always be checked to see if it is not *, but that would probably be superfluous.