Closed Bug 1343950 (csp-unsafe-hashes) Opened 7 years ago Closed 1 year ago

Content Security Policy (CSP) implement unsafe-hashes


(Core :: DOM: Security, task, P3)




110 Branch
Tracking Status
firefox109 --- fixed
firefox110 --- fixed


(Reporter: luke.semerau, Assigned: tschuster)


(Blocks 1 open bug, )


(Keywords: dev-doc-complete, parity-chrome, Whiteboard: [domsecurity-backlog1])


(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

Example HTML:
<meta http-equiv="Content-Security-Policy" content="script-src 'unsafe-hashed-attributes' 'sha256-XTqNqFSUlZHAW7f/OGNYSOEzxKhjdAAGMXoid2VEbJk=';">
<button onclick="alert('hi')">click me to say hi</button>

Click on button.

Actual results:


 Content Security Policy: Couldn’t parse invalid host 'unsafe-hashed-attributes'

 Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src 'sha256-XTqNqFSUlZHAW7f/OGNYSOEzxKhjdAAGMXoid2VEbJk='”). Source: onclick attribute on BUTTON element.

Expected results:

Alert with 'hi' should shown.
Component: Untriaged → DOM: Security
Product: Firefox → Core
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]

This seems to have been renamed to 'unsafe-hashes'

Ever confirmed: true
Summary: Content Security Policy (CSP) implement unsafe-hashed-attributes → Content Security Policy (CSP) implement unsafe-hashes
Blocks: csp-w3c-3
Type: defect → task
See Also: → 1683506
Blocks: 1788864
Alias: csp-unsafe-hashes
Severity: normal → S3
Depends on: 1797070

did you fix it? if so, how?

Blocks: 1805948
Assignee: nobody → tschuster
Pushed by
CSP: Enable the 'unsafe-hashes' keyword by default. r=freddyb
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 110 Branch
Blocks: 1806845
Duplicate of this bug: 1807024

We've received multiple reports about Microsoft Azure data factory breaking since changes in bug1797070. It's currently broken on release (108) and fixed in Nightly (110) by this patch (confirmed with mozregression --find-fix).

Hi Tom, following up on your comment3 from bug1806845 , wonder if it's possible to uplift this patch to Beta and maybe release since there might be a lot of users affected?

Flags: needinfo?(tschuster)

Comment on attachment 9308661 [details]
Bug 1343950 - CSP: Enable the 'unsafe-hashes' keyword by default. r?freddyb

Beta/Release Uplift Approval Request

  • User impact if declined: Previously working websites were broken. Hard to workaround for websites without decreasing their security.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This was tested in Nightly already. Most of the code already existed, but now is "opt-in" (via 'unsafe-hashes') for websites.
  • String changes made/needed: n/a
  • Is Android affected?: Yes
Flags: needinfo?(tschuster)
Attachment #9308661 - Flags: approval-mozilla-beta?
Duplicate of this bug: 1806845

Comment on attachment 9308661 [details]
Bug 1343950 - CSP: Enable the 'unsafe-hashes' keyword by default. r?freddyb

Not super crazy about taking this so late in the beta cycle, but I'm also not crazy about leaving sites broken for another cycle. Approved for 109.0b8 but let's be on the lookout for any regressions.

Attachment #9308661 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Duplicate of this bug: 1806613

Tracking issue for MDN updates

You need to log in before you can comment on or make changes to this bug.