Hey everyone, Aituglo here. I’m a full-time bug hunter mainly focused on access control bugs. There are so many different types of vulnerabilities concerning access control that it can be hard at first to choose the right category for testing. In bug hunting, two common vulnerability types are account takeover (ATO) and access control. They might sound similar—both allow an attacker to do things they’re not supposed to be able to—but they are actually quite different. Understanding these differences can help a lot in reporting bugs effectively. We will break down what each means, analyze some real-world examples, and learn how to identify them. Knowing the differences between these two vulnerability types will help you locate the appropriate impact for the asset you are hacking.
An ATO is exactly what it sounds like: it’s when an attacker gains unauthorized control of someone else’s account. Essentially, the attacker is able to log in to and access a victim’s account or session. An ATO attack occurs when a malicious actor gains access to a user’s account by guessing or obtaining the user’s password or session token. Even simple flaws in authentication or session management mechanisms are considered bugs.
There are a variety of tricks at our disposal to achieve ATO. Some common ATO-related vulnerabilities relevant to bug bounty include the following.
Many ATOs happen because of flaws in the “Forgot Password” process. For example, if an application uses predictable or non-unique password tokens, an attacker might guess or reuse a token to reset someone else’s password. Or if their reset link doesn’t properly verify a user’s identity (using an insecure direct object reference [IDOR] in a reset endpoint), an attacker can reset another user’s password by modifying a user ID parameter. A classic scenario is an IDOR in a reset password form that lets you choose which account to reset, allowing a full ATO of other users (a nice critical bug).
Another method I love using to gain access to an account is by leveraging XSS. By exploiting XSS on a website, you can then perform anything a user can normally do on their account. To prove the impact of an XSS exploit, it’s absolutely not enough to show only an alert pop-up. It’s imperative to be able to access user data or to modify it, and a common way to achieve this is via ATO. But how? This depends on the context of an application, and it’s usually by modifying a user’s email or password. In doing so, you can then reset the password and access the account. So, when the victim is subjected to an XSS attack, we make a request to modify their account and email, and then we gain access to their full account. The highest impact usually comes from finding an XSS on an application.
You can typically use an IDOR to view or modify user data, but it can also be useful for achieving an ATO. For instance, if you can modify a user’s email, you can then reset their password and eventually gain access to their full account. Sometimes, you can also directly modify a user’s password if the login process doesn’t ask for the previously used password. Pro tip: by doing mass assignment in forms, you can sometimes modify a user’s last name. Go a step further and try to add an email in the request to also modify it. 😉
There are tons of different ways to exploit these flaws, and the most common is usually a misconfiguration. The easiest way to achieve an ATO is by finding an open redirect in the login flow. This way, you can receive the code used to gain the access token needed to log in to an application.
If you find a CSRF directly on the modified user email page, you can also easily find the user and change their email by using an email you own. From there, you can then reset the password and gain access to the full account.
Access control is about who is allowed to perform actions on an account or see inside an account. Once a user is authenticated, it’s necessary that the application enforce rules around permissions. This is so that users can only access the resources and actions they have permission to. Thanks to OWASP, access control is how an application grants access to certain content or functions for specific users and not others, with checks performed after authentication. A broken access control vulnerability exists when those rules are not properly implemented, allowing users to bypass permissions.
To simplify, an access control flaw means User A can access something belonging to User B or perform an admin-only action—this should not be allowed. These bugs are very common and don’t necessarily require you to take over someone’s entire account. Instead, you can simply exploit an application’s lack of proper permission checks.
Access control issues can take many forms. I discuss a few in the following.
My personal favorite, IDOR is easy to spot when you’re trying to change the IDs or parameters as you’re trying to access other users’ data. IDOR happens when objects are referenced by an identifier (like a number or a name) in a request and an application does not properly verify that a user should have access to that object. For example, a banking application might have an endpoint/api/transactions/12345 that returns transaction details for transaction ID 12345. If User A is logged in and simply changes the ID in the URL or request to 12346 (User B’s transaction) and the app returns User B’s data to User A, that’s an IDOR. The app failed to check and ask, “Does this request belong to User A?” This is a very common issue. Depending on what data is exposed (e.g., sensitive data like PII or financial data), the severity level of this vulnerability varies.
Such issues occur when a user with lower privilege (like a normal user) can perform an action reserved for higher-privilege roles (like an admin). For instance, suppose there is an admin panel at /admin/dashboard that should only be accessible to admins, but an app forgets to check role permissions. If a simple user can access that page or make admin-only API calls, that’s a vertical privilege escalation. Another example is when a user can promote themselves to admin by modifying their own account and setting their role to admin (e.g., by doing a mass assignment). These issues often occur due to missing checks on the server side. The consequences can be huge; an attacker might gain the ability to manage other users, view all data, or manipulate accounts.
BOLA, popularized by the OWASP API Security Top 10, reflects essentially the same concept as IDOR but is often cited in the context of APIs. Each object (like a record identified by an ID) should have an authorization check. If those checks are missing, any user can access any object by guessing IDs. It’s the number-one issue in API security for a reason.
Essentially, any time you can do something you are not supposed to because an app is not checking permissions, it falls under this category.
Now that we’ve defined each, let’s compare them. While both are serious issues that have high impact, they target different parts of an application.
ATO usually targets the authentication stage, like the process of logging in or maintaining a session. Access control issues usually occur after authentication, when a user has already logged in.
In an ATO, an attacker eventually gains access to the entirety of a victim’s account, so the attacker can do anything the user can do with their account. With an access control flaw, the complete control of someone else’s account is not required but you can still manage to gain access to data or functions not intended for you. ATO is like stealing an identity, while access control is more about breaking the rules of what any person can do.
ATOs arise from weak authentication practices, like no two-factor authentication (2FA), weak password reset, predictable tokens, or other mechanisms. Access control bugs occur due to missing or flawed authorization logic (i.e., an app fails to check if a user is allowed to take certain actions).
Both ATO and access control vulnerabilities can be considered high-severity bugs. Usually, an ATO is a P1 or P2, depending on the context. Sometimes there isn’t much to do with an account. Broken access control is associated with a wider range of severity levels, from P1 when you can access the PII or financial data of all users to P4 when it’s only about leaking a user image profile, for instance.
Both ATO and access control vulnerabilities can occur in complex cases, but the aim of testing is always to demonstrate the highest impact. This is why it’s so serious when you find an ATO; it directly shows that you can access the entirety of a user’s account, not just part of it.
By understanding the differences between ATO and access control, you can change your testing approach. For example, you can test and check the login and reset flows for ATOs, as well as check different endpoints for access control issues. Each requires a different mindset when hunting.
Always keep in mind that sometimes, a small flaw can have big consequences. For example, a simple IDOR could expose all user data or only the age of a user. Always evaluate and communicate the right impact in your reports.
Armed with tips, resources, and examples, any bug hunter can gain a clear understanding of these vulnerabilities and spot them. With practice, you will get better at finding them, and you will see that they are absolutely everywhere. I make a living based on this fact. 😉
Happy hunting, and see you on the leaderboard.