Hacker News Reader

Comment by philip1209 | Hacker News Reader

> User own resource id should be avoided. Use /me/orders instead of /user/654321/orders

Can somebody explain this?

By making the owner's userid implicit, you're foreclosing on the possibility of authorization bugs where an endpoint fails to verify that the current user is authorized to see orders from user 654321.

Basically, avoid literal (insecure direct object) references to resources where possible so you have fewer areas where a server can goof authorization checks. Preempt the possibility of a server expecting any direct reference and structure your API to only load resources from a backend, not the user's input.

This goes hand in hand with abstracting all authorization checks to a single gateway/middleware layer that each call inherits, rather than a spot check per call or a group of checks for different groups of calls.

(This is in addition to what 'lvh and 'tptacek have said already.)

I believe its because its a more explicit indication that the route MUST have access control logic etc baked in.

It also conveniently makes a CSRF vulnerability easier to exploit. And, as soon as there's more than one of something (e.g. say a family/corp account with an administrator that can do something for different users), it falls apart.

I think this is an interesting security consideration but I would prefer implicit identity for the following reasons:

If the API is meant to be consumed by machines then it's unlikely that CSRF would be a threat.

CSRF controls are more likely to be provided out of the box by a framework. Authorization controls are often tightly coupled to the business domain and are less likely to be usable out of the box.

If you need to support a scenario where administrators perform tasks on behalf of other users, then I would suggest evaluating whether a sudo-like mechanism could be viable solution.

Let's say you are the user 654321. You see that you can access your private page at /user/654321. You then try to access /user/112233: if the developer forgot the authorization controls, or inserted bugs, you can access other users' informations

what happens if I type in /user/654322/orders instead of /user/654321/orders? Did I just access someone else's account?

Yes, if you're a supervisor or parent account or something like that.

Preventing flexibility at the URL level rather than performing proper authentication strikes me as a poor decision.

I think this is a rather special usecase, this makes sense with inhouse applications where something like this might be common, but probably not something you want on the public api of a shop.

I disagree. What about the support rep, who needs to look at the customer's orders? What if it's a e.g. digital games store, and you want to have kids accounts which can be reviewed by their parents' ? What if you sell to businesses, and you want to let employees purchase stuff without having access to the address and billing info, which is configured by a master account?

You're just tying yourself down for no good reason.

Generally you’ll just get a 403 response. There’s still authentication taking place, I’d imagine this tip in particular is just to protect from revealing any potentially dangerous identifiers.

Reply on news.ycombinator.com