Is there a security advantage to requiring a request to conform to /api/1234 instead of /api/me? Both would obviously have access tokens.

My guess is that api/1234 is more secure because if someone gets hold of an access token, they can't just see who's it is. They have to know which user id the token belongs to.


Short answer: It doesn't matter

In some cases using /api/1234 could be a disadvantage. If the application lacks proper authorization checks, a user could try /api/1235 and access another user's account. This kind of vulnerability is surprisingly common in practice. /api/me is good because it forces the developer to fetch the ID from the session.

/api/1234 can be an advantage if the user ID is a secret. This depends on the application - usually with interactive applications, users can see other users' IDs. If the ID truly is secret, this protects against CSRF. However, you application should already have CSRF protection, usually through a token in a hidden field.

In general, if someone gets hold of an access token, all bets are off. Focus your security effort on stopping anyone getting hold of a token.

| improve this answer | |

Yes it's true that they would need an additional piece of information if you require the user id as well, so I suppose it is more secure.

That said, I suspect if an access token was stolen then it is likely that the user id was stolen as well. Even if it was not, if you are using sequential IDs (like your example does) and not GUIDs or something then they could just fire off a request for /api/1 through /api/1000000 and see if they get any positive hits.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.