Twitter | Pretraživanje | |
Mike West 8. sij
I took some time to sketch out `Scripting-Policy` in a little more detail: . I'm starting to think it might actually not be a terrible idea.
Reply Retweet Označi sa "sviđa mi se"
Mike West
It's like the CSP: The Good Parts. Most users would be well-served with a policy like `Scripting-Policy: nonce=number-used-once`, and I think even complex deployments can be supported with a limited set of options. We can keep it small and focused, with a clear threat model.
Reply Retweet Označi sa "sviđa mi se" More
Mike West 8. sij
Odgovor korisniku/ci @mikewest
Feedback would be welcome, either here or as issues/PRs filed on the GitHub repository: . Thanks!
Reply Retweet Označi sa "sviđa mi se"
Craig Francis 8. sij
Odgovor korisniku/ci @mikewest
And I’ve not really given this any thought as to actually using this, but “If a policy sets requirements for both a nonce and some set of integrity, either will be sufficient to allow script execution” - I was initially hoping I could require both checks to pass.
Reply Retweet Označi sa "sviđa mi se"
Craig Francis 8. sij
Odgovor korisniku/ci @mikewest
You’re right for the default, I’m just wondering if there would be any advantage for a very strict system requiring both. I’m currently using (although browsers ignore) CSP require-sri-for, so I already have those hash values, but wonder if requiring a nonce might add something.
Reply Retweet Označi sa "sviđa mi se"
Craig Francis 8. sij
Odgovor korisniku/ci @mikewest
Initial reading looks good. Quick question though, is there a reason why eval is set to "allow" by default? I would expect it to be “allow-trustedscript” to push developers away from this unsafe function, but also introduce them to TrustedTypes.
Reply Retweet Označi sa "sviđa mi se"
Mike West 8. sij
Odgovor korisniku/ci @craigfrancis
Typo. It should have been `allow-trustedscript` to match the description in . I'll fix that up.
Reply Retweet Označi sa "sviđa mi se"
koto 8. sij
Odgovor korisniku/ci @mikewest
1. Looks pretty good! 2. Why strict-dynamic for non-parser-inserted scripts? It feels like TT for such scripts would be a better fit here long term, especially if they appear already for eval.
Reply Retweet Označi sa "sviđa mi se"
Mike West 8. sij
Odgovor korisniku/ci @kkotowicz
Two answers: 1. I didn't think about it, file an issue, let's chat! 2. My initial reaction is that I'd like to maintain behavior similar to CSP. The migration story is likely to be fraught as-is (); consistency seems valuable to mitigate confusion.
Reply Retweet Označi sa "sviđa mi se"