Add a more strict default

[damienbod]

addresses #202

Not sure if I got everything right, API yes, unsure about the UI headers.

Another point, when using OIDC, the form self definition will block some flows. Maybe a documentation note about the CSP.

Greetings Damien

[damienbod]

I fix the tests today

[damienbod]

fixed the tests

[andrewlock]

Hey Damien, I haven't forgotten about this, I've just been mulling it over a lot and trying to understand all the implications of the various COOP, COEP, CORP headers 😅

One thing I was wondering about, is whether it's worth adding additional "default" values. e.g. the existing ones are meant to be "safe" headers that generally improve security. I feel like maybe there's for additional "collections" to serve as a basis, e.g.

• Locked down - a strict CSP, permissions policy, everything same origin etc
• Blazor - strict where possible, but lets through the various blazor-required holes
• OIDC - to let various common things associated with OIDC through

It's just a vague idea though, and I'm not sure how feasible they are, as I suspect most of the time people will need to customize, which is fine, but in that case, having additional "default" values may make it more confusing to know where to start. I'm not sure, just thinking out loud really :D

[damienbod]

Hi @andrewlock no problem, I am thinking along these lines as well. I try to lock the each app as much as possible and so I would end up never using the defaults as each app is slightly different. If using defaults, then you have a basic security set which is a lot better than nothing but missing a few things. This would work with almost any type of APP which is the advantage.

Maybe just lock down the API defaults and leave the UI defaults as it is is a type of in the middle approach.

Maybe the question is who are defaults made for and then optimize for this developer type.

It is good as it is as well, maybe we can just close the PR and leave the defaults.

I'm thinking out loud as well :) No idea what is best, but it is not that important as we can always just create our own definitions.

[andrewlock]

Ok, I've done some more thinking about it and a bunch more reading and playing with COOP/COEP/CORP...

I think for the UI headers, the way to go is to be generally more broadly applicable. For me, that means

• Cross-Origin-Opener-Policy - I'm very torn on this one. I've already rolled it out as same-origin, but otherwise I would probably have gone with same-origin-allow-popups to make it more broadly applicable, while still providing some protections. That said, having same-origin does provide the option for enabling crossOriginIsolated mode, which is a mark in it's favour...
• Cross-Origin-Embedder-Policy - currently we're not applying anything, but I think using credentialless might be a good middle ground? It would mean we're crossOriginIsolated applicable again, plus you can make cross origin requests without further changes that way (as long as you don't need credentials to access the resource, and if you do then you should probably already be using request.mode = 'cors' etc) WDYT? 🤔
• Cross-Origin-Resource-Policy - same-origin and same-site both seem valid here, but given same-site gives that slightly broader option without reducing the footprint much, it might be a better option...

For the APIs I think what we already discussed makes sense, i.e.

• Cross-Origin-Opener-Policy: same-origin
• Cross-Origin-Embedder-Policy: require-corp
• Cross-Origin-Resource-Policy: same-site

[damienbod]

@andrewlock I like the middle ground solution you suggested.

Updated.

Greetings Damien

[andrewlock]

Thanks Damien, appreciate it!