Nuxt.js: How can I protect $nuxt in console ?

[achen224]

What problem does this feature solve?

$nuxt should not show in console

What does the proposed changes look like?

give $nuxt a scope and user can not use $nuxt by console

_{This feature request is available on Nuxt community (#c8436)}

[pi0]

Hi. You can use globalName property to change the reference to a random secret one.

[achen224]

Thx @pi0 ,
But use globalName user still can call all fucntion by console

[pi0]

Even by not exposing a reference to the window object one can use other tricks like getting vue reference from DOM elements to access $nuxt (If not changed). Security is all about hardening. Assigning a random name would be the best solution:

{
  globalName: Buffer.from(Math.random() + '').toString('base64').substr(0, 5)
}

[achen224]

ok, I just think it's too easy to access

Thx for reply

[Atinux]

Hi @achen224

Thanks for the feature request.

I am trying to well understand what's the problem here, could you explain us a bit more what's the security issue of exposing $nuxt?

[AndrewBogdanovTSS]

@Atinux yes, I also can't grasp what is the real issue here. Since JS is always fully exposed there is no real benefit in trying to hide some parts of it. @achen224 I think you should protect your server better, not the client

[manniL]

To sum it up here:

No advantages for the adversary

Having $nuxt in window scope does not increase the "power" of an adversary. Even if $nuxt wouldn't be accessible, the javascript is loaded in the browser and you can easily reach for the root Vue instance with a few console commands. So the only argument to remove $nuxt is "it's too easy to access it".

$nuxt is useful

$nuxt is important for transitions, devtools detection, onNuxtReady hooks and more.

A word about hiding security-related things

Security through Obscurity is no valid security concept. If you website has an XSS-vulnerability, the adversary will always find a more or less easy way to access the Nuxt/Vue instance.

[paulvonber]

@manniL I think you're not really realising what you talking about... yes it's very secure to expose things like env variables.

[manniL]

@paulvonber No worries, I know exactly what I’m talking about 😁

yes it's very secure to expose things like env variables.

This is a whole other topic and not related to that issue. If you somehow expose env variables accidentally, they are available in the JS source and therefore in the client anyway. With or without $nuxt, one could access them 🤷🏼‍♂️

If you re-read my statement from above, you will realize that a potential adversary will have the same power with and without $nuxt as one can set breakpoints in the debugger of the browser anyway

[paulvonber]

Probably nuxt team accidentally exposing them as well.

I notice you don't see any difference between typing $nuxt and trying to dig into js with debugger,
According to you security doesn't exist and you can just print stuff on your home page because anyway everyone can find whatever they want.

[manniL]

Oh no 🙉 You’ve discovered the public Algolia API key!

I’d rather stop answering now as ad hominem arguments are not worth my time ☺️

[paulvonber]

@manniL your answers and arguments tells a lot about your knowledge. And whatever it is Algolia or anything else the fact is that the stuff is visible and it’s a hole.

[manniL]

your answers and arguments tells a lot about your knowledge

I think so too 😋
Especially because I know the difference between a public and a private key 😂

But back to the topic:

1. Do your research, because from what I can read you are misinformed a little ☺️
2. I don’t like to repeat myself, but just for you: this is not a security issue, while showing private API keys would be (but that’s not what the issue is about after all :) )
3. If you have well-researched arguments, go ahead and open an issue with your thoughts.
4. If you eventually don’t like the decision, then feel free to fork Nuxt and do whatever you like