Content Security Policy support

[benmccann]

I don't see anything in the code related to CSP support, so I'm guessing that doesn't exist yet unless I missed it.

Sapper supports it via %sapper.cspnonce%: https://sapper.svelte.dev/docs#Content_Security_Policy_CSP

[dominikg]

I stumbled over nonce-based csp support in sapper before: sveltejs/sapper#1175

May need a different approach in kit depending on the adapter being used (capability to generate nonce for every request?)
Imho nonce should only be used where a) it has to be an inline item and b) the data contained does not only change on build but at runtime (dynamic ssr). Whereever possible inline items should either be properly hashed or extracted.

That being said, what level of csp support are we looking at?
No unsafe-* required?

[acoyfellow]

Hi - it looks like this (mostly) can be solved with hooks now, in the handle function.

no nonce's yet but i'm working on it, maybe someone can see that solution

https://gist.github.com/acoyfellow/d8e86979c66ebea25e1643594e38be73

[furudean]

Technically a duplicate of #72, but this issue has better info so lets go with this one?

Oops, CSP is not the same as CSRF!

[seanlail]

@acoyfellow Great work so far!

I just want to highlight that it's really important that eval is not used in SvelteKit.
Can we ensure that there is no unsafe use, as @dominikg has suggested.

I've just been looking at an issue in Sapper here where the issue is that we have to allow unsafe-eval, which defeats the purpose of using CSP.

cc/ @Conduitry (as we were talking about this in the other ticket).

[Rich-Harris]

Noting this, from Twitter:

is there any way to move the inline script for SvelteKit to an external one? I’d like to enforce a stricter CSP, but currently need unsafe-inline to accommodate. Thanks!

For server-rendered pages we could just use a nonce, I think? For pre-rendered pages that's no good, we would need to generate a hashed file (say /boot/xyz123.js) for each unique script.

[dominikg]

could still hash inline content: https://content-security-policy.com/hash/

and pass the hash in a policy via meta in head https://content-security-policy.com/examples/meta/

I'm not sure if meta policies are additive though so may not be ideal.
external scripts would work best as those are covered by self, no hash required

[Karlinator]

As far as I can see it's only the init script in the head, right? Nothing else is inline? Or does this depend on build configurations/adapters?

In any case meta policies are allowed alongside HTTP policies. However, any source must pass all specified policies, meaning if you wanted to load scripts from a CDN it must be specified both places and the HTTP header must still send unsafe-inline. Basically, generating CSP in more than one place is kind of a mess.

See: https://www.w3.org/TR/CSP3/#multiple-policies

Putting the init script in a separate file is a much better option imo.