1

At work, we have a Nuxt.js app, and there has been some discussions about a bug bounty report pointing to the fact that you can access the Vue instance from window.__NUXT__.

I haven’t found any posts or articles concerned about this, so I'm wondering if this is actually a vulnerability or not. What do you think? Is there a way a 3rd party can get access to a user's window.__NUXT__?

The main concern is that you could access the Vuex state (and the api tokens stored inside) through window.__NUXT__.state.auth...

kissu
  • 40,416
  • 14
  • 65
  • 133
Jon O'Reilly
  • 75
  • 4
  • Erm, if there is a third party code which can access `window` then by definition, it has access to everything on the client. Therefore, by definition it has access to all the data. Even if it's not exposed via `window`. I don't think exposing something as a global property is any less secure than the client already is. – VLAZ Jul 27 '22 at 09:55

1 Answers1

4

As somehow explained in my other answer here: https://stackoverflow.com/a/69945576/8816585

A frontend is not secure by design because everything is exposed to the end user. He could literally open his devtools and inspect everything indeed.

Is it an issue per se? No.
Can it be risky if a third-party access some data with it? Yeah, as pretty much any package that you're using in your package.json basically. It's not more risky.

Then, should you store some private tokens on the frontend? Probably not.
If using JWT or a solution alike, yeah you can totally have publicly facing tokens. Since those are meant to be refreshed often and are harmless like any other public key (like in SSH).

The tokens just don't need to be private, for those only a server-side solution is viable (like a stripe secure token for example).

kissu
  • 40,416
  • 14
  • 65
  • 133
  • Oh, I see. So because the frontend can never be 100% secure, any stored value can be considered risky. And therefore we should only use user-specific tokens to limit the possible access for a 3rd party. Thanks for the answer! – Jon O'Reilly Aug 04 '22 at 09:31