Per-route CSP configuration

[vejja]

Hi @Baroshem

I would like to have your opinion on per-route functionalities in the module.
Currently the doc says that it's possible to define per-route CSP via the router's headers property:

export default defineNuxtConfig({
  // Per route
  routeRules: {
    '/custom-route': {
      headers: {
        'Content-Security-Policy': <OPTIONS>
      },
    }
  }
})

However
1- TS does not like 'Content-Security-Policy' other than string
2- The module does not support the functionality: the header value is set as Content-Security-Policy: [Object object]

What is your intention for per-route functionality ?
Should 'Content-Security-Policy' be provided as a string or as a ContentSecurityPolicy object ?

[Baroshem]

Hey Buddy,

I think the object or a string. It is basically because some people prefer to put all header value as a string while others want to have better and clearer approach of an object.

If you are encountering issues that are opposite to what documentation says, it is a bug and we should fix it.

However the main intention is to allow users to set different headers per route as there might be different cases that we are not aware off (let's say and embedded checkout or google maps embed, etc)

[Baroshem]

Maybe. But I am not sure tbh.

Could you please create an issue for that? We will work on it to fix it for the next RC version or stable. I am not expecting many new features right now so I think we are approaching th stable stage :)

[vejja]

Issue #292

[vejja]

@Baroshem
I did some tests and I'm happy to submit a PR to solve the issue but before doing that I'd like to clarify some issues that I am facing:

1. We are using the security.headers property in the main module configuration, but we are using the headers property in the per-route configuration, which is a native property of the Nitro radix router
2. We want to allow both object syntax and string syntax, but the Nitro radix router only allows string syntax.
3. There are only 3 headers for which we can have conflits : Content-Security-Policy, Permissions-Policy, and Strict-Transport-Security

I am not convinced that overriding the native type definitions of the Nitro radix router is a good solution. I think it is not maintainable over the long term, and it may conflict with how other modules interact with routeRules.

I think it would be better to:

• Use the string syntax for the native Nitro headers property of the radix router: people who want to use the standard string syntax can use it under the native routeRules.{{route}}.headers configuration property;
• Use the object syntax for our custom security.headers property: people who want to use our object syntax can use it under our custom routeRules.{{route}}.security.headers configuration property.

This would have 3 implications:

1. We would have to modify the docs :

Old Syntax

export default defineNuxtConfig({ // Global security: { headers: { contentSecurityPolicy: <OPTIONS>, }, }, // Per route routeRules: { '/custom-route': { headers: { 'Content-Security-Policy': <OPTIONS> }, } })

New Syntax

export default defineNuxtConfig({ // Global security: { headers: { contentSecurityPolicy: <OPTIONS>, }, }, // Per route routeRules: { '/custom-route': { headers: { // Route headers are defined as usual with string syntax 'Content-Security-Policy': <string> }, security: { headers: { // Security headers are defined here with object syntax // They take precedence over the previous ones in case of duplicate contentSecurityPolicy: <OPTIONS> }, } } })

2. We would still maintain backwards compatibility: If a legacy user used the old syntax, we would still support the syntax but it would become deprecated. We can do this via Javascript type check even if TypeScript disallows the object syntax.

3. We would clarify that security.headers takes precedence over headers in case both fields are defined: The only thing that we need to do is to properly defu the security headers into the main headers.

Let me know your feedback !

[Baroshem]

Hey Buddy,

Thanks for this extensive research. I really like the idea of everything work the same for both global and per route configuration.

And now, I see where the issue is! You are correct, the documentation is wrong. The route rules should not accept options object here but a string instead.

I will create a fix asap.

For the new syntax that you want to propose.

I think the new syntax and updated docs could be better (we would have one approach with just a small difference of adding routeRules).

But we would need to be extra careful to not cause any breaking changes so we would need to maintain both approaches (native nitro headers and our own security.headers).

Then I think we would be fine with it to deliver a great and standarized value to all users :)

[Baroshem]

#296

[vejja]

But we would need to be extra careful to not cause any breaking changes so we would need to maintain both approaches (native nitro headers and our own security.headers).

Agree, this has to be done super carefully...

[Baroshem]

@vejja

Could you please create an issue for implementing this route rules security headers approach?

Also, regarding the priority of this.

Do you think we could an it for the 1.1.0 release?

I would like to publish 1.0.0 in the upcoming days before I will be going for some short vacations the week after so it will be a week or more break from me actively developing this project (I will be answering questions and answering discussions however) :)

[vejja]

Let's do it for 1.1, WDYT ?
It will need to be extensively tested and it won't break 1.0, so better release 1.0 now I would say

[Baroshem]

Sounds good! I have added it to the 1.1.0 milestone :)

[vejja]

PR #304

[Baroshem]

The feature was implemented and released. Amazing work as always @vejja 💚