Hello! π Today, we’re going to easily and thoroughly explore the highly anticipated #1 vulnerability in the OWASP Top 10 2021, Broken Access Control, which every developer and security professional must know. Having jumped from 5th place in 2017 to 1st, it’s a truly important and commonly found vulnerability, so please pay close attention!
π€ Access Control? What is it?
To put it simply, it’s like a ‘key’. π
- Homeowner: Has a master key that can enter all rooms. (Administrator)
- Family: Has keys to their own room, living room, and bathroom. (Regular User)
- Outsider: Has no keys and cannot enter the house. (Unauthenticated User)
As such, Access Control is a core security principle that verifies who a user is and what permissions they have, controlling them to perform only authorized actions. In other words, it’s a system that decides “You can open this door” or “You cannot press this button”.
‘Broken Access Control’ refers to a state where this key system is faulty. It’s a terrible situation where an outsider can freely enter my room, or a regular user can access a secret space that only administrators should access. π±
π¨ Why did it become #1?
According to OWASP, some form of Broken Access Control vulnerability was found in 94% of analyzed applications. This means almost all web applications are exposed to this problem. This is often because user authentication (login) functionality is well-built, but the logic to meticulously check each user’s permissions on every page after login is frequently overlooked.
π΅οΈββοΈ Common Types of Broken Access Control
In what cases can access control be said to be ‘broken’? Let’s explore some typical examples.
1. Insecure Direct Object References (IDOR)
This is the most common and intuitive type. It’s an attack where a simple number (ID) in a URL address or parameter is changed to access another person’s information.
- Attack Scenario π§βπ»
- A hacker checks their own post. The URL is
- Curious, the hacker changes the ‘id’ value in the URL to 101 and makes a request. (
- If the server does not verify that this request is from a legitimate user, post #101 (another person’s private post) is exposed as is!
2. Privilege Escalation
This occurs when a user obtains higher privileges than they originally had. It is broadly divided into two types.
- Vertical Privilege Escalation π©βπΌ β‘οΈ π
- This is when a regular user gains administrator (Admin) privileges.
- Example: Discovering the administrator page URL (
- Horizontal Privilege Escalation π€ β‘οΈ π€
- This is when one user accesses the information of another user of the same rank.
- Example: IDOR, as explained above, is a typical horizontal privilege escalation attack. It’s accessing another user’s information by going from user/123 to user/124.
3. Missing Function Level Access Control
This is when a specific button or menu is hidden in the user interface (UI) to prevent access, but the server does not prevent access to that function.
- Attack Scenario π
- The ‘Delete User’ button is not visible to regular users.
- However, the hacker finds the API address for the ‘Delete User’ function (
- If this address is called directly and the server does not verify that the requesting user is an administrator, user #50 is deleted as is.
π‘οΈ How can we prevent it? (Defense Methods)
The core principle for preventing Broken Access Control is simple: “Trust no one, suspect every request!”
- Deny by Default π This is the most important principle. All access should be blocked by default until specific permissions are explicitly granted. It’s easy to think of it as a whitelist approach.
- Implement Centralized Access Control Logic βοΈ Scattering permission check logic everywhere makes mistakes prone to happen. Permissions should be managed in one place, and all requests should be designed to pass through this centralized logic.
- On the Server! For Every Request! Perform Permission Checks π₯οΈβοΈ Hiding something on the user’s screen (client) is meaningless. When every request reaches the server, it must be re-verified on the server side whether the user is authorized to perform that action.
- Principle of Least Privilege Grant users only the minimum necessary permissions. There is no need to give regular users access to administrator functions.
- Use Unpredictable IDs Instead of sequential numeric IDs like 1, 2, 3, using complex and unpredictable UUIDs (Universally Unique Identifiers) like a1b2c3d4-e5f6-…. can make IDOR attacks much more difficult.
β¨ Conclusion
Broken Access Control can stem from very minor mistakes, but the consequences can be extremely severe, ranging from personal information leaks to system takeover. The complacent thought of ‘this much will be fine’ is the biggest enemy.
How about starting today to get into the habit of always asking yourself, ‘Does the user who sent this request truly have the authority to perform this action?’ for every feature you build? It will be the first step towards creating a safer web world!
Leave a Reply