Why can I see private page being logged out?

[Maclay74]

So, since this is authentication, why am I able to see private page without being logged in?
Anyone can just open a dev tools and find content of private page.

Isn't it supposed to be up to server to decide whether private information should be sent or not?
Because now server sends everything, but client doesn't show it. Which is obviously not enough in terms of security.

Maybe I don't understand something?

Thanks.

[iaincollins]

Great question! This is an aspect of Single Page Apps we could help explain better (and probably need to).

When using Client Side Rendering to protect pages any text on the page will be theoretically accessible to anyone in this way unless the content is served from behind a server side route.

e.g. where the page fetches content from an endpoint like /api/content/123 that checks the session or JWT

The expectation with an SPA is that you are comfortable with the page templates being visible to people in this way, but the actual data that is sensitive is served via API (e.g. a list of users if it's a user dashboard, or bunch of data if it's a graph, or article text if it's a news site with a paywall, etc) and that it enforces that they must be authorized to view the data.

If you are not comfortable with this, you can move even the template data exclusively behind server side rendered pages using getServerSideProps() on the page itself (with the caveat that this will impact page speed).

[nyedidikeke]

The current behaviour meets a specific scenario.
Could we consider an additional one were an unauthenticated user attempting to view a protected page/content is automatically redirected to a specific route/page (eg: the login page)?

[Winwardo]

Something that might be worth calling out as a caveat in documentation, is that any JS in the default exported function of a NextJS page can (and will eventually) be accessed by an attacker.

You are right that any templated data behind a getServerSideProps() call will be correctly protected. If however you have a route that does an SSR redirect but still shows sensitive information (not externally fetched data) on the page component itself, it's possible to follow the JS through webpack+Next to find those files.

An example (apologies if these links break in the future):
https://next-auth-example.now.sh/private
When not logged in, this says "You must be signed in to view this page", and when logged in, it says "You can view this page because you are signed in."

An unauthenticated attacker can go to https://next-auth-example.now.sh/_next/static
and thus https://next-auth-example.now.sh/_next/static/HfIvDtVyV02d3QN9F35UT/_buildManifest.js
which has the following:
"/private":[a,"static\u002Fchunks\u002Fpages\u002Fprivate-232a1983152ac1ad166b.js"]

Following that URL takes us to
https://next-auth-example.now.sh/_next/static/chunks/pages/private-232a1983152ac1ad166b.js

which contains the phrase:

as per https://github.com/nextauthjs/next-auth-example/blob/main/pages/private.js

This is not to say that it's not worth doing an SSR redirect, but more that when using NextJS, you should assume that all component JS could be publically visible to anyone. If data is sensitive, it must be brought in either through getServerSideProps or on the client as a fetch.

NextJS does not currently provide a way to require authentication for JS or CSS - and given the NextJS/Vercel/JAMstack goal of "serve static files as quick as possible", I wouldn't expect to see this anytime soon.

Also to be clear, this is not a bug in next-auth! This is outside the remit of an SPA authentication library - it's just an important caveat worth knowing about if you care about the security+visibility of your JS.

[Maclay74]

Thanks for your answers!

It's definitely not a bug or an issue of next-auth, but probably we should clarify it somehow for users.
If we could have an example of protecting data by getServerSideProps, it would be marvelous.

And if this solution can be implemented out of the box, I think it's worth to consider it to be default one.

[iaincollins]

I've updated the example project at https://next-auth-example.now.sh

• Client Side Protection https://github.com/nextauthjs/next-auth-example/blob/main/pages/protected.js
• Server Side Protection https://github.com/nextauthjs/next-auth-example/blob/main/pages/protected.js
• API Route https://github.com/nextauthjs/next-auth-example/blob/main/pages/api/examples/protected.js

Client Side Protection with this approach is the fastest method and is secure, the Server Side Protection method is not more secure but will work for devices that do not support JavaScript (with some performance cost).

In practice you'd probably want to do something like use JSON, Markdown or HTML for protected content (e.g. from a database or API) and handling loading states a bit better (e.g. using useSWR() to fetch the content) but I hope this gives folks some idea of how best to approach securing content on protected pages.

I agree with @mikecoon's comment that we probably should make it clearer what the dangers are.

[jachinte]

@iaincollins Is there a way to trigger the sign in process from the server? That is, instead of displaying a message saying "access denied", trigger an open id connect sign in. I tried using signIn("my-custom-client") but it requires a window object. And redirecting to /api/auth/signin/my-custom-client requires the user to click on a button to actually open the sign in page.