Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NuxtLink Support with custom route rules #527

Open
markus-gx opened this issue Sep 23, 2024 · 5 comments
Open

NuxtLink Support with custom route rules #527

markus-gx opened this issue Sep 23, 2024 · 5 comments
Assignees
Labels
bug Something isn't working

Comments

@markus-gx
Copy link

Version

------------------------------
- Operating System: Darwin
- Node Version:     v20.5.1
- Nuxt Version:     3.13.2
- CLI Version:      3.13.2
- Nitro Version:    2.9.7
- Package Manager:  [email protected]
- Builder:          -
- User Config:      future, app, hooks, routeRules, runtimeConfig, swiper, css, components, modules, image, security, postcss, vite, extends, compatibilityDate, formkit, plausible, cookieFirst, shopware
- Runtime Modules:  @storyblok/[email protected], @nuxtjs/[email protected], @pinia/[email protected], @nuxt/[email protected], @shopware-pwa/[email protected], [email protected], @formkit/[email protected], [email protected], @nuxtjs/[email protected], [email protected]
- Build Modules:    -
------------------------------

Steps to Reproduce:

  1. Set up custom route rules (e.g., configure specific security headers for PayPal on a checkout route).
  2. Reload the page where the custom route rules are applied (e.g., the checkout route) and verify that the custom security headers are correctly applied.
  3. From a different page, use <nuxt-link> to navigate internally to the page where custom route rules were set.
  4. Upon navigating to the page via <nuxt-link>, observe that the custom security headers are no longer applied.

Expected Behavior:

Custom route rules should persist and be applied correctly, even when navigating internally via <nuxt-link>. The custom headers (e.g., for PayPal on the checkout route) should still be present, ensuring consistent security behavior.

Actual Behavior:

The custom route-specific security headers are not applied when navigating internally using <nuxt-link>. Instead, the default global nuxt-security settings are applied, overwriting/not applying the expected custom route headers.

Additional Information:

  • The issue seems to occur only during internal navigation using <nuxt-link>. When directly accessing the route (e.g., via a page reload), the custom headers are correctly applied.
  • The problem may be related to the way Nuxt handles client-side navigation and applies route-specific rules during internal transitions.
@markus-gx markus-gx added the bug Something isn't working label Sep 23, 2024
@vejja
Copy link
Collaborator

vejja commented Sep 26, 2024

Hi @markus-gx

I was going to give you the all-frustrating "it's not a bug, it's a feature" but I do have to say it's an issue.
Unfortunately this is completely outside our control, and it all relies on Nuxt having its roots in client-side Single-Page Applications, while CSP is a server-side specification defined at page-level.

The issue that you are facing is that when you navigate on the client-side, your application is not hitting the server again. Everything happens in the browser, so the headers are not refreshed.

We have an extensive write-up about this issue in our docs here: https://nuxt-security.vercel.app/documentation/advanced/strict-csp#per-route-csp
Our recommendation is to not use routeRules for headers if you can. Instead, try to define a single policy that will cover your entire application.
If you absolutely need to enforce route-level security rules, our recommendation is to force a page-reload upon entering and leaving the specific route.

We discussed internally whether we would drop the routeRules feature and decided to keep it for some advanced use cases.
Maybe we should rewrite the docs to hide it somewhere deep in the documentation, and surround it with big warnings...

@vejja vejja self-assigned this Sep 26, 2024
@markus-gx
Copy link
Author

Thanks for the answer! Totally understand that - hiding is always great :P

@Baroshem
Copy link
Collaborator

I would be up for hiding it as well but not removing it as someone might need it. Thanks for the answer and comments! :)

@Baroshem
Copy link
Collaborator

@markus-gx

Would you be interested in contributing this documentation change? We can provide all help needed :)

@markus-gx
Copy link
Author

Sure count me in ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants