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

Unable to use httpOnly attribute for authCookie #851

Open
maximehamou opened this issue Aug 9, 2024 · 1 comment
Open

Unable to use httpOnly attribute for authCookie #851

maximehamou opened this issue Aug 9, 2024 · 1 comment
Labels
bug A bug that needs to be resolved help-needed Action needed: The help of the community would be appreciated p3 Minor issue provider-local An issue with the local provider

Comments

@maximehamou
Copy link
Contributor

Environment

  • Operating System: Darwin
  • Node Version: v22.6.0
  • Nuxt Version: 3.12.3
  • CLI Version: 3.12.0
  • Nitro Version: 2.9.7
  • Package Manager: yarn@1.22.22
  • Builder: -
  • User Config: ssr, app, css, runtimeConfig, modules, apiParty, auth, plugins, components, build, devServer, compatibilityDate
  • Runtime Modules: nuxt-api-party@2.0.8, @sidebase/nuxt-auth@0.8.2
  • Build Modules: -

Reproduction

Turn on httpOnlyCookieAttribute to true in nuxt.config.js. Try to login and refresh the page.

Describe the bug

Hello,
I opened a pull request yesterday (that has been merged).
The issue, like I said in the PR, is that the cookie is not saved after logging in if we set httpOnlyCookieAttribute to true (this is enabling httpOnly attribute for the cookie, preventing JS access and thus XSS attacks). This is caused by the way the cookie is saved. Indeed, the cookie is saved by useCookie and watch method in useAuthState file composable (see here), and this is client-side.
To fix the issue (what I am trying to work on), we have to change the way of defining the cookie, from client-side to server-side. With this, the cookie will be created, saved, modified or deleted on server-side, thus we will be able to use httpOnly attribute for the auth cookie, providing us a better app security.
I would really appreciate some help on this!
Thanks you.

Additional context

No response

Logs

No response

@maximehamou maximehamou added bug A bug that needs to be resolved pending An issue waiting for triage labels Aug 9, 2024
@phoenix-ru
Copy link
Collaborator

I see your point - you want to attach cookies server-side instead of manually setting them on the client. This is very tricky due to the fact local provider works with both Nuxt/non-Nuxt backends and authentication markers (cookies, etc.) greatly differ between all of them.
useCookie is mostly used to preserve state (i.e. tokens) within the session and cookies being set on SSR is mostly a side-effect.
I agree that it's better if JS has no access to the cookie, however in that case we also have no reliable way of knowing the authentication state:

  • SSR sees the cookie and says that a user is authenticated -> renders authenticated view;
  • CSR hydrates but doesn't see the cookie -> hydration mismatch -> renders unauthenticated view.

Not relying on useCookie at the client means that authentication state needs to be correctly set on the server and then transferred and preserved in memory during the session. This is of course doable but requires noticeable effort to think through and implement. I would love to hear your take on how it can be implemented using known building blocks of Nuxt (like useCookie and useState).

Concepts are welcome

@zoey-kaiser zoey-kaiser added p3 Minor issue help-needed Action needed: The help of the community would be appreciated provider-local An issue with the local provider and removed pending An issue waiting for triage labels Aug 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A bug that needs to be resolved help-needed Action needed: The help of the community would be appreciated p3 Minor issue provider-local An issue with the local provider
Projects
None yet
Development

No branches or pull requests

3 participants