4 ms·

> User own resource id should be avoided. Use /me/orders instead of /user/654321/orders Can somebody explain this?

• ben_jones 9y ago
  I believe its because its a more explicit indication that the route MUST have access control logic etc baked in.
  • lvh 9y ago
    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.
    • tofflos 9y ago
      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.
• s_m_t 9y ago
  what happens if I type in /user/654322/orders instead of /user/654321/orders? Did I just access someone else's account?
  • icebraining 9y ago
    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.
    • kpcyrd 9y ago
      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.
      • icebraining 9y ago
        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.
  • bdibs 9y ago
    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.
• tptacek 9y ago
  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.
• dsacco 9y ago
  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.)
• riquito 9y ago
  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