Limiting CSP header to HTML responses only

[prashantpalikhe]

Currently, if we enable the CSP header via the module, it adds the CSP header to all the responses including the static assets from _nuxt directory. We can override that by setting the header to an empty string in Nitro's routeRules but that still sends the header with the response, just as an empty string. We could also define the route for the CSP config itself, but that's tricky e.g. in my use-case where there is just one catch-all route and the pages are dynamically served with content from a headless CMS.

IMO, the CSP header should only be applied to HTML documents. So that the header is not present at all in other kinds of resources served by Nitro.

[Baroshem]

Hey,

That sounds interesting indeed.

What are your thoughts @danielroe ?

[prashantpalikhe]

@Baroshem Not to be implemented?

[Baroshem]

Hey, there was no interest in this discussion for about 5 months so I decided to close it.

Are you looking for this feature?

[vejja]

Hey @Baroshem
Actually I believe @prashantpalikhe is correct: doesn't make sense to send CSP headers on non-HTML resources.
i.e. routes such as /api functions and /_nuxt static assets don't need to serve these headers.

Interestingly fix/nonce-ssg does exactly what he was suggesting, i.e. send the CSP header with an empty string on pre-rendered routes. Even more interesting is his suggestion that only html resources would get the CSP header.
It's a much cleaner solution but this means changing our logic: Instead of adding the CSP header on all routes via middleware, wait for Nitro to render the html and add the CSP header only at that point.
Let's keep it in mind and investigate whether feasible ?

[Baroshem]

Sounds like a good idea to me!

Lets reopen this issue an maybe keep it in mind for the next rc versions? What do you think? Or should it be like a next minor version (like 1.1.0)?

[vejja]

Maybe a next major ?

[Baroshem]

When saying 1.1.0 I meant minor, not major. But we can also make it for major like 2.0.0 but honestly I dont really know how much time it will take for the 2.0.0 as it tooked more than a year to reach to RC 😀

@vejja do you maybe have an estimation how much effort and changes this improvement would mean?

[vejja]

We are not that far away with PR #275

[vejja]

PR #304 fully implements

[Baroshem]

Closing as it was released with 1.0.0-rc.5 :)