[tshaddox]

“Bypasses auth” is a weird way to put it, although everyone seems to describe it in those terms. It bypasses middleware, which is bad (and embarrassing for Vercel), but middleware shouldn’t be responsible for access control. The middleware shouldn’t be doing much more than redirecting to the sign-in page if you don’t have a session.

[ibash]

Why shouldn’t middleware be responsible for access control?

[jonny_eh]

That should be the server. Your Nextjs app should have zero access to business data without at least an auth token. And if you're relying on middleware for auth, it'll be responsible for providing that auth token to the rest of the app. And if you bypass middleware, then there's no auth token, and no vulnerability.

This is only a vulnerability if you have pages you don't want to render for some people, regardless of upstream data it would need to fetch.

[quonn]

Not necessarily. There is no big difference whether the business logic resides in the same node process or another one. If the first process is unsafe on that level, then the token can also be extracted.

[ibash]

Middleware runs server side doesn't it? tbh I haven't used nextjs middleware. But in many frameworks have used middleware that provides overarching access control.

For example having all routes under `/admin/*` automatically return an error if the user is not an admin, and then the individual routes don't need to be concerns with access control.

[5Qn8mNbc2FNCiVV]

The issue is, everyone uses middleware because Next.js doesn't provide a primitive for a middleware like how it's done for any other framework. Just something to execute before your endpoint, that's it.

They haven't had one for years and everyone wrapped their endpoints which was error prone and also flat out annoying, it's reasonable that people then jump to middleware

[RadiozRadioz]

Sorry I am new to Next, and I expect others are too. In Express, middleware runs on the server, and it's a common pattern to handle authentication checks in there before the request reaches any routers. Are you saying that the "middleware" described here is purely a client-side thing? If so, I agree, it's silly to put any kind of auth in there. But the language on the Next website made me think that this was server-side; the mention of the cookie validation (which should not happen on a client), and the mention of the deployment type. I was also under the impression that Next was a framework that spans the client and the server.

So to confirm: where does this middleware run?

[deergomoo]

> redirecting to the sign-in page if you don’t have a session

Is this not access control?

[NorwegianDude]

Yes. Yes it is. I guess this person has the same stance Vercel now has. Even Next.js docs can make up their mind of whether you should or should not do it. They reccomended it until yesteray, but then another major securityflaw was discovered that made it useless, and now they removed authentication from the docs.

The takeaway is that you should not do it. You should never use Next.js if you ever has somehting that is not supposed to be public for everyone.

No serious company uses Next.js after all the recent major security issues, at least not if they have and respect users data.

[bilater]

yeah i guess it depends on your app...if your whole paid tier relies on access to protected pages where the check happened in middleware then its a big issue, but if have additional checks there such as checking userid and subscription inside routes then its not as big of a deal as the user in theory wont be able to do anything.

BTW ppl are talking about why middleware should be used for auth and, while I don't like this pattern, it is the adopted pattern for app router in nextjs and services like clerk and supabase use it heavily.

[teaearlgraycold]

Yeah in practice this will let people see the structure of admin pages they wouldn’t normally get to see. But not any data.