- From: Craig Francis <craig.francis@gmail.com>
- Date: Wed, 8 Jan 2020 15:59:32 +0000
- To: Mike West <mkwst@google.com>
- Cc: Web Application Security Working Group <public-webappsec@w3.org>
- Message-ID: <CALytEkNGxbWLNqDg+qBnr9GEAvMxm=QG40q4vCxTHgGUo3NV_A@mail.gmail.com>
Thanks Mike, Scripting-Policy does look like a simpler process for developers to mitigate the most common XSS issues (and Trusted Types can hopefully help the next set). As to confinement, I think CSP does this pretty well already. So I'd like to keep CSP as it is, although you could deprecate some parts (e.g. the hash/nonce options). Then CSP can focus on limiting where resources can be loaded from, which is good for ensuring developers put things in the right place, but it's also an extra set of restrictions if an attacker does find a way to run their evil code (be that JS, malformed HTML, etc). Craig On Wed, 8 Jan 2020 at 10:18, Mike West <mkwst@google.com> wrote: > Hey folks, > > At TPAC last year, we discussed > <https://github.com/w3c/webappsec/blob/master/meetings/2019/2019-09-TPAC-minutes.md#csp> > the CSP Next proposal <https://github.com/mikewest/csp-next> in a little > bit of detail. It seemed like there was general approval of the vague > contours of the idea, so I took some time to sketch it out in a little more > detail. I'd appreciate feedback (directional and detail!) on > https://mikewest.github.io/csp-next/scripting-policy.html. > > This addresses the XSS mitigation portion of CSP. It doesn't touch the > confinement portions of CSP discussed in > https://github.com/mikewest/csp-next/#resource-confinement. I'm quite a > bit less clear on what that would actually need to look like. If y'all have > ideas (especially those rooted in actual experience deploying > confinement-oriented policies), I'd love to hear about them. > > Thanks! > > -mike >
Received on Wednesday, 8 January 2020 15:59:46 UTC