Closed
Bug 809983
Opened 12 years ago
Closed 12 years ago
Update CSP mappings to allow for future Content Types
Categories
(Firefox :: Security, defect)
Firefox
Security
Tracking
()
RESOLVED
DUPLICATE
of bug 809982
People
(Reporter: tanvi, Unassigned)
References
(Blocks 1 open bug)
Details
Comments from bsmith in bug 802905:
> > Also, need to make sure that CSP handles unknown content types like
> > TYPE_OTHER, to match the required behavior described in the comments for
> > TYPE_OTHER that were added to this patch.
In the new documentation in nsIContentPolicy, it says that content policy implementations must treat unknown types the same as they treat TYPE_OTHER. So, let's take an arbitrary unknown content type like 55. csp._MAPPINGS[55] is null, which means CSP will not block the content. But, instead, CSP should handle the content just like it does for csp._MAPPINGS[TYPE_OTHER], which maps to cspr_sd.DEFAULT_SRC. (I think the best way to resolve this is to have null mean DEFAULT_SRC, and have a new explicit value for "CSP cannot block this" instead of using null to mean that. But, there are other ways of doing it.)
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•