Disable client hydration in Nuxt.js or Stop exposing raw data in Nuxt.js

Question

I creating a Web App that using Nuxt.js, with Server-Side Rendering.

I don't want expose my backend data, so I tried to use asyncData and Axios to request to my backend server.

But the Nuxt.js exposed my backend data to client with window.__NUXT__.data variable.

I tried remove this by using render:route hook, But It says

[Vue warn]: The client-side rendered virtual DOM tree is not matching server-rendered content. This is likely caused by incorrect HTML markup, for example nesting block-level elements inside p, or missing . Bailing hydration and performing full client-side render.

So I tried remove the script that making not matching error, But It makes stop working script at my site.

So the question: How to disable the client hydration(client-side virtual DOM tree rendering)? or How to stop exposing raw data?

I used asyncData with this code:

asyncData ({ params, error }: { params: { id: string }, error: Function }) {
  return axios.post('(backend)', data).then(res => res.data ? ({ data: res.data }) : error({ statusCode: 400, message: 'Bad request' }));
}

I'm working on the same problem. I don't want to expose that data. — Ozgur, Jan 10 '20 at 14:19
Why do you want to hide some data here? What's the actual use-case that is going against the basics of the Web (sharing)? — kissu, Dec 21 '21 at 10:08
Stopping client hydration will cause your website to not listen to events, etc. If this is not a problem for you, I can share with you a script that stops the hydration and you won't see the error — Arik, Dec 22 '21 at 22:42
@arik I'm curious to see this solution. Meanwhile, I'm not sure that adding even more JS to your bundle is the way to go here. It's probably quite the opposite idea initially I guess. So even if it's somehow possible, it's probably the worst thing to do. Or did you maybe achieved to make Markus project work somehow with Nuxt2? — kissu, Dec 23 '21 at 02:03

score 3 · Answer 1 · answered Dec 21 '21 at 10:07

You cannot stop the hydration of your SSR'ed content (not yet at least, it is planned to server only static content pretty soon tho).
Nuxt is aimed to add SSR to your day to day VueJS SPA. If you don't want the hydration, you're probably using the wrong framework here anyway.
Astro may be a better fit, to name just one. You could find more here too.

The DOM mismatch issue is explained here (reasons + solution).

How to hide things on the client side?

Short answer: you can't.
Long answer available here.

If you want to display something on a page, you'll need data.
Nowadays we're using SPAs to have a local state in the browser. Since it's local and under your eyes, the state is living in your browser, so you can't really hide it and also, why would you do that?
If you want to hide the data, maybe don't send it initially or send an image at least.
You could also make some obfuscation, but this will just be a band-aid and not really good on semantics/performance/etc...

If you have some sensitive data that you want to show only to admins or so, you could use some auth and rights checking. More details above, in the long answer.

score 1 · Answer 2 · edited Dec 21 '21 at 11:50

If you really really want to hide data on plain sight, that is, you want to send data on client-side without exposing it, then you do not have a full solution for that as it is, but there are ways to achieve what you need, choose your preference based on your intent.

Not sending data to the client if you do not want to expose it

Yes, I know you have asked for the diametrically opposite, but, before you read the really, really unconventional and often difficult approaches, first, let's ponder on whether you really need this indeed. The alternative would be to just not send this data to the client at all, but rather work with this sensitive data on the server. It is the scenario you will need 99.9999% of the cases of web-development. (the number is my subjective estimation, not the result of a representative statistical research)

Email, chat, SMS, paper mail, smoke signals, morse messages

You may need to send that information for the client, but this does not automatically mean that you will need to send it to the client-side of your website. You could send the information using some other channel, just make sure that it's trusted and reliable. For this reason I don't really recommend the use of smoke signals.

iframe

Now to the technicalities. Modern browsers protect against the scenario when you have webpage1 opening webpage2 in an iframe if they happen to have a different domain. So, you can create a domain that's different from the one your main page uses and show whatever you want to the client by calling a page of your brand new second domain (via HTTPS, of course), using minimized Javascript and closures. If you need communication between your iframe and your main page, then you can use messaging between the two, see Communication between tabs or windows.

A possible objection may be that one can still see the network tab of his/her browser where the actual received data is being shown as well as the possibility to debug Javascript. Well, bad luck. We cannot send the data to the client without sending it to the client. If this caveat is too much of a risk, then read on.

Encode the content you want to avoid from exposure

Yup, it will create a lot of difficulties and sometimes you will wish you never did it, but you can encode your top secret data and even if the user has access to it, he/she will have no idea what it is. But in this case you will need to face the problem of encrypting/decrypting your data whenever you use it.

You can use visual representation of your data

Like an image, an svg or some other kind of generated captcha-like content, but don't send it a file, because a third-party watcher may just download it. If you generate that inside an iframe, then your data is difficult to mine. Oh, wait, but what if the hacker looks at your screen from behind your chair?

Write your own browser (extension?)

You can implement a browser or a combination of browser extensions that will handle this and use HTTPS. But what if the spy has a lucky day and deciphers it? What if you have a virus?

Bottom-line

By the sheer fact that you are sending data to the client-side you will have to accept some risks. There is no way around it. You can reduce those risks, but it's always safer not sending the data than sending it.