Authenticated user on web app, using other people's id to update or change their information. So basically the web app is not checking for person who is logged in against the person who he/she is updating the information. Is there specific name for this type of attack?

4 Answers 4


To me it sounds like IDOR, Insecure Direct Object Reference, which OWASP defines as, "Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files. Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks". I think IDOR sounds very similar to Broken Access Control, but i think this case is a case of IDOR.

More on this at: http://www.jtmelton.com/2010/05/10/the-owasp-top-ten-and-esapi-part-5-insecure-direct-object-reference/

  • I am choosing this answer as the closest to answering what I am asking. Especially for providing owasp reference since I am talking about web app.
    – DoodleKana
    Mar 13, 2015 at 18:22
  • @DoodleKana Glad i could help! :) Mar 13, 2015 at 18:38

...sounds to me like Improper Access Control.

From CWE-284:

Description Summary The software does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

Extended Description Access control involves the use of several protection mechanisms such as authentication (proving the identity of an actor) authorization (ensuring that a given actor can access a resource), and accountability (tracking of activities that were performed). When any mechanism is not applied or otherwise fails, attackers can compromise the security of the software by gaining privileges, reading sensitive information, executing commands, evading detection, etc. There are two distinct behaviors that can introduce access control weaknesses:

  • Specification: incorrect privileges, permissions, ownership, etc. are explicitly specified for either the user or the resource (for example, setting a password file to be world-writable, or giving administrator capabilities to a guest user). This action could be performed by the program or the administrator.

  • Enforcement: the mechanism contains errors that prevent it from properly enforcing the specified access control requirements (e.g., allowing the user to specify their own privileges, or allowing a syntactically-incorrect ACL to produce insecure settings). This problem occurs within the program itself, in that it does not actually enforce the intended security policy that the administrator specifies.

However, you don't mention how the actor is carrying out their attack - so I can only guess they are using GET parameter manipulation to impersonate another user.

In this case the actual attack would be "Parameter Manipulation" or "Parameter Tampering".


I always use the Web Application Security Consortium classification. You may use it to classify the threat regarding two of its aspects:

Attack (the method used to achieve the result) and
Weakness (the flaw that was exploited by the attack)

Using that classification, the attack should be categorized as Abuse of Functionality (as you are entitled to change your own information, but not other's) and the weakness as Insufficient Process Validation (as the application should know that that info belong's to someone else and that you're not allowed to change it).


Identity Masquerade.

However, I feel that the method -- not the damage -- should be named. Therefore, I would simply refer to this as an authentication bypass.

  • 1
    probably in combination with a direct object reference
    – wireghoul
    Mar 10, 2015 at 21:51
  • If you take it literally, authentication was not bypassed as the user was required to correctly provide his credential before exploiting the app. Mar 10, 2015 at 22:28
  • Hmm true. Maybe identity traversal? It's not really an "escalation" unless the target user has higher rights than the attacker's. Actually I still might call this an authentication bypass, because you are obtaining access to an account you have not authenticated for.
    – armani
    Mar 11, 2015 at 16:35

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.