# What Is Broken Access Control? IDOR, BOLA and Authorization Vulnerabilities

**URL:** https://securesys.com.tr/en/learning/web-application-security/broken-access-control-idor-bola

### What Is Authorization?

![What is Broken Access Control? IDOR, BOLA and authorization vulnerabilities](/images/bilgi-merkezi/covers/cover-broken-access-control.webp)

A user logging into a web application does not mean they should be able to access every resource. While authentication verifies who the user is, authorization determines what operations they can perform.

A well-designed authorization mechanism ensures each user only accesses the data and functions appropriate to their role. When these controls are missing or incorrectly applied, an attacker can access data belonging to other users, escalate their privileges, or use management functions they should not reach. This is called **Broken Access Control**, and it is one of the most critical risks on the OWASP Top 10 list.

### Why Is It the Most Critical Vulnerability?

Many organisations focus their security investments on technologies such as firewalls, antivirus or WAF. However, if there is a flaw in the application's own authorization logic, an attacker who has logged in can reach critical data without needing to bypass those security layers. Such vulnerabilities often cannot be detected by automated scanners, because the problem stems less from a technical flaw and more from incorrect application of the business rules.

### Types of Broken Access Control

#### \1. Horizontal Privilege Escalation

In this scenario the attacker accesses data belonging to another user at their own privilege level. For example, in an e-commerce application a user opens `/orders/5481`; if by simply changing the order number to `/orders/5482` they can access another customer's order details, a critical authorization vulnerability exists.

#### \2. Vertical Privilege Escalation

Here the user gains privileges above their own role. If a normal user can access `/admin/users` or call APIs meant only for administrators, there is a serious authorization problem.

#### \3. IDOR (Insecure Direct Object Reference)

One of the most frequently encountered authorization vulnerabilities today. If the application only checks the object identifier (ID) when accessing a resource without verifying whether that resource actually belongs to the user, an attacker can view different records — for example, sending `invoice?id=1002` instead of `invoice?id=1001` to open another customer's invoice.

#### \4. BOLA (Broken Object Level Authorization)

A modern variant of IDOR seen especially in REST API applications. If a `GET /api/users/125/profile` request does not verify that the requesting user is actually user 125, the attacker can read other users' records. This risk is very common in mobile applications and micro-service architectures.

### A Real-World Scenario

In a finance application, users could track their credit applications online. During the penetration test it was found that the application number appeared in the URL, and by simply changing that number, applications belonging to different customers could be viewed. Technically the system had no SQL Injection, XSS or RCE vulnerability; yet solely because of a missing authorization check, identity documents, income statements, credit scores and application results could be viewed by other users.

### SecureSys Authorization Testing Approach

Authorization vulnerabilities cannot be reliably detected with automated tools alone, so we place manual analysis at the centre of our testing process. Our tests cover role-based access controls, user-switching scenarios, ID manipulation, API object access, tenant isolation in multi-tenant applications, and server-side validation mechanisms.

### How Can Authorization Vulnerabilities Be Prevented?

- Authorization must be checked server-side on every request.
- User identity must not be determined by trusting data coming from the client.
- Role-based (RBAC) or attribute-based (ABAC) access control must be applied.
- Object-level authorization must be verified at API endpoints.
- All access attempts must be logged and monitored regularly.

### Risk and Business Impact

| Risk | Business Impact |
| --- | --- |
| Viewing customer data | KVKK and GDPR breach |
| Altering financial records | Financial loss |
| Unauthorised administrator access | Loss of control over critical systems |
| Data exfiltration via the API | Mass data breach |

To have your application tested against Broken Access Control, IDOR and BOLA risks, review our [Web Application Penetration Testing Service](/en/services/web-application-security-test-service) page, and for an API-specific assessment our [API Security](/en/learning/web-application-security/api-security-owasp-api-security-top-10) page.