Closed
Bug 1806114
Opened 2 years ago
Closed 2 years ago
Mixed content level 2 should not upgrade when request's mode is CORS
Categories
(Core :: DOM: Security, defect, P3)
Core
DOM: Security
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: t.yavor, Assigned: t.yavor)
References
Details
(Whiteboard: [domsecurity-active])
Attachments
(1 file)
|
(deleted),
text/x-phabricator-request
|
Details |
Mixed Content level 2 is upgrading embedded elements even if CORS is enabled.
According to the standard this is not the order we should process a request.
That means we should restructure our upgating algorithm for MCL2
|
Assignee | |
Updated•2 years ago
|
Assignee: nobody → lyavor
|
|
Assignee | |
Updated•2 years ago
|
|
||
Updated•2 years ago
|
Summary: Mixed content level 2 is upgrading before CORS triggered → Mixed content level 2 should not upgrade when request's mode is CORS
|
||
Updated•2 years ago
|
Severity: -- → S3
Type: task → defect
Priority: -- → P3
Whiteboard: [domsecurity-active]
|
|
Assignee | |
Comment 1•2 years ago
|
||
|
||
Updated•2 years ago
|
Attachment #9310985 -
Attachment description: WIP: Bug 1806114 - Mixed content level 2 should not upgrade when request's mode is CORS → WIP: Bug 1806114 - Mixed content level 2 should not upgrade when request's mode is CORS r=freddyb
|
|
||
Comment 2•2 years ago
|
||
In analyzing existing browser behavior, we have instead decided to change the spec: Apparently no browser has ever marked CORS requests as blocked and just considered them as mixed display content. On top, Chrome already upgrades CORS requests as part of their mixed content lvl2 implementation.
The comment in https://github.com/w3c/webappsec-mixed-content/issues/63#issuecomment-1386714463 (and the thread around) has more information and additional pointers to spec and wpt changes.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•