Excessive CSP error logged for inline scriplet injection

[argothiel]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is NOT a YouTube, Facebook or Twitch report. These sites MUST be reported by clicking their respective links.
• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

On sites whose CSP uses a nonce on script-src/script-src-elem (so 'unsafe-inline' is neutralized) but explicitly allows blob:, uBO's scriptlet injector logs a CSP violation error on page load, even though scriptlet injection itself succeeds.

This is a side effect of the fix in #235 by @gorhill . uBO's Firefox main-world injector tries a synchronous inline <script> first (to preserve execution-order guarantees before page scripts run), and falls back to a blob: URL if that's blocked. On CSP configurations like the one below, the inline attempt always fails – the nonce means the browser will never make an exception for it – so the fallback always succeeds, but not before Firefox logs a violation.

If we verify the CSP response headers, we could easily avoid this error noise, while keeping the functionality the same. Namely, since uBO already receives the page's CSP response headers in onHeadersReceived, it can evaluate ahead of time whether 'unsafe-inline' would be honored for a given hostname (nonce/hash/'strict-dynamic' present) and skip straight to the blob: path when it won't, instead of attempting and failing every time.

A specific URL where the issue occurs.

https://www.threads.com/

Steps to Reproduce

1. Load https://www.threads.com/ with uBO enabled and default filter lists active (default Cookie Notices consent scriptlets trigger this – no custom rule needed).
2. Open the browser console.
3. Observe the CSP violation logged on load. (Reproduction can be intermittent on the very first load – a separate, unrelated timing issue in the same code path sometimes makes the inline attempt fail before it even reaches the CSP check, silently. If no error appears, reload once or twice.)
4. Disable uBO and reload – the error no longer appears, confirming it originates from uBO's scriptlet injection attempt.

Expected behavior

No CSP violation logged – the fallback already handles this case correctly, so the error is spurious noise about an attempt uBO could have skipped.

Troubleshooting information

uBlock Origin: 1.72.2
Firefox: 152
filterset (summary):
 network: 182732
 cosmetic: 43243
 scriptlet: 33623
 html: 3642
listset (total-discarded, last-updated):
 default:
  user-filters: 0-0, never
  ublock-filters: 52748-73, now
  ublock-badware: 10287-27, now
  ublock-privacy: 4064-2, now
  ublock-unbreak: 2841-1, now
  ublock-quick-fixes: 488-13, now
  easylist: 86800-140, now
  easyprivacy: 55952-40, now
  urlhaus-1: 48005-11, now
  plowe-0: 3523-1030, now
filterset (user): [empty]
userSettings: [none]
hiddenSettings: [none]
supportStats:
 allReadyAfter: 1111 ms
 maxAssetCacheWait: 20 ms
 cacheBackend: indexedDB

[gorhill]

If we verify the CSP response headers, we could easily avoid this error noise

"Easily" should really never be used unless a properly designed fix is provided at the same time. Such fix requires:

• Looking up Content-Security-Policy header
• If found, a parser to extract the effective policy, and whether this policy allows inline script elements.
• Keep track the of result so that it can be used by the script injector code

And this still doesn't address content-security-policy injected through meta tags.

There is a already Firefox issue opened about this: https://bugzilla.mozilla.org/show_bug.cgi?id=1267027

I declined fixing this. Whoever feels strongly about this is free to submit a pull request, but I can't guarantee I will accept it if I judge the required code change is unreasonable.