You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Document Policy document notes that there's some potential overlap with CSP, at least insofar as the sandbox directive exists. It's not entirely clear to me what DP aims to address, and what its scope actually boils down to, but there might be more overlap. Consider the following:
script-src offers control over specific APIs like eval() via the unsafe-eval keyword. Similar proposals exist to gate WASM via some other keyword.
trusted-types controls TT enforcement.
block-all-mixed-content can be seen as a restriction on Fetch, but it could also be a feature toggle insofar as it sets a flag on the document context.
upgrade-insecure-requests is similarly situated.
plugin-types gates <embed> and <object>
navigate-to aims to address navigation-related issues.
https://github.com/mikewest/csp-next suggests that we should really break these kinds of mechanisms out of CSP, and into something else. That document focuses on script execution, defining a scripting-policy concept that would probably encompass the unsafe-eval bits and maybe the plugin bits? Perhaps Document Policy would be a reasonable home for the rest?
The text was updated successfully, but these errors were encountered:
That sounds like a good fit -- with the possible exception of 'navigate-to', which might benefit from CSP's rich source-list syntax. The other directives all focus on what a document can do, once loaded, without necessarily forcing the same restrictions on nested content, which is the model document policy is trying to cover.
clelland
transferred this issue from w3c/webappsec-permissions-policy
Dec 1, 2020
The Document Policy document notes that there's some potential overlap with CSP, at least insofar as the
sandbox
directive exists. It's not entirely clear to me what DP aims to address, and what its scope actually boils down to, but there might be more overlap. Consider the following:script-src
offers control over specific APIs likeeval()
via theunsafe-eval
keyword. Similar proposals exist to gate WASM via some other keyword.trusted-types
controls TT enforcement.block-all-mixed-content
can be seen as a restriction on Fetch, but it could also be a feature toggle insofar as it sets a flag on the document context.upgrade-insecure-requests
is similarly situated.plugin-types
gates<embed>
and<object>
navigate-to
aims to address navigation-related issues.https://github.com/mikewest/csp-next suggests that we should really break these kinds of mechanisms out of CSP, and into something else. That document focuses on script execution, defining a
scripting-policy
concept that would probably encompass theunsafe-eval
bits and maybe the plugin bits? Perhaps Document Policy would be a reasonable home for the rest?The text was updated successfully, but these errors were encountered: