Hacker News new | ask | show | jobs
by bdangubic 449 days ago
expect you know, when you can bypass auth by adding an http header :)
1 comments

Not that this isn't a serious attack vector (a possible one), but most implementations are not simply using middleware as a standalone check for authorization then blindly serving paths/content up.

That'd be pretty bad architecture in any stack.

so having "some protections" like db foreign key scoping that mitigates "well anyone can now bypass auth middleware for any route" makes this…

"not that bad on nextjs part"

no no, this is absolutely nuts.

Some of you are ready for an argument, you responded to my post yet seemingly missed the very first sentence fragment:

>Not that this isn't a serious attack vector

At no point did I say or imply what you put in quotes.

I disagree. Why pollute every function with code checking for auth if you can just do it in a middleware?
The middleware should fetch auth, not check it. Each page should check the auth provided by the middleware. Skipping middleware wouldn't bypass anything in this case.
If each page has different criteria, sure, but if not, why? Let's say I simply care if the user is a paying member. I don't see why I wouldn't just have that in the middleware.
You don't do it everywhere. You do it in the source system. The Next.JS application should just be doing "sanity" checks and passing along identity information at most. That belongs in the middleware layer, but it's not authoritative.

If bypassing a middleware layer is the one "trust me bro" check you have in your web app, then lol.

That's actually really hilarious and you should tell me what company/website that's for so I can submit some bug bounties.

Isn't next.js the "source system" (or whatever that means) in most cases, since most apps are just next.js + database? I don't use next.js but my understanding is it does both backend and frontend.

You will never bypass middleware on my services because they actually always run. If you can't rely on your middleware then you are using the wrong tech.

I haven't heard any good reason as to why not have auth in your middleware lawyer. Just attempt to shrug it away as a "trust me bro" check. Are if statements trust me bro too? Only thing you shouldn't be doing is using garbage software like next js

From next.js homepage > Middleware > Take control of the incoming request. Use code to define routing and access rules for authentication, experimentation, and internationalization.

>Isn't next.js the "source system"

Absolutely not. You are pulling from something else. If you need authorization to view a page that means it's more than likely not going to be SSG or ISR, so both the Next.JS application and the source system should be doing authorization checks.

>If you can't rely on your middleware then you are using the wrong tech.

"If you can't rely on server less functions to run"

I mean, I can't help you there if that's your expectation that serverless functions will always run correctly.

>Just attempt to shrug it away as a "trust me bro" check.

If you lose identity and your system just chugs along anyway then there isn't a tech stack in the world that can help you.

>I haven't heard

Because you're being a dense muppet?

> I mean, I can't help you there if that's your expectation that serverless functions will always run correctly.

Crashing, failing I/O, are expected. What's not expected is logic code being ignored. I can't take you serious when you think it's acceptable to just skip past parts of your code.

If you think bypassing middlewares is acceptable you are completely deluded. But I guess that's needed to pay $150/TB for bandwidth.

you probably need to re-define “most” :)