Broken Authorization

Introduction

After a user is successfully authenticated, the application must decide what that user is allowed to access or perform. This decision is called authorization. Authentication verifies identity, but authorization verifies permissions. A user may log in correctly and still be denied access to an admin operation, another user's record, a sensitive field, or a business workflow that belongs to a different role.

Broken Authorization occurs when those permission checks are missing, incorrect, inconsistent, or too trusting. It is one of the most serious API security problems because the attacker does not always need to bypass login. The attacker may simply use a valid account and attempt operations beyond the account's permission level. This makes the risk harder to notice in normal happy path testing because the user appears legitimate.

APIs are especially vulnerable to Broken Authorization because API requests often expose resource IDs, methods, paths, request bodies, and field names directly. A user can change `/users/101` to `/users/102`, call an admin endpoint directly, send hidden fields in a JSON body, or use a different HTTP method than the UI normally uses. If the backend API does not validate permission for each resource and action, the user may access data or functions that should be protected.

Several risks in the OWASP API Security Top 10 relate directly to authorization. Broken Object Level Authorization, Broken Object Property Level Authorization, and Broken Function Level Authorization are all authorization failures. For API testers, this means authorization testing is not optional. It is a core part of validating whether the API is safe for real users, real roles, and real business data.

What Is Broken Authorization?

Broken Authorization is a security vulnerability where an API fails to properly verify whether an authenticated user has permission to access a resource or perform a specific action. The user may have a valid token, valid session, or valid login, but the API allows access beyond the user's assigned permissions.

A simple definition is this: Broken Authorization happens when authenticated users can access resources or perform actions they should not be allowed to access or perform. For example, an employee deletes another employee's record, a customer views another customer's order, a guest calls an admin endpoint, or a normal user updates a restricted field such as role, salary, credit limit, or account status.

Broken Authorization is dangerous because it often looks like normal API usage. The request may include a valid token. The endpoint may exist. The data format may be correct. The only problem is the permission decision. If the application checks only identity and forgets to check permission, the attacker can operate as an authenticated but unauthorized user.

Authentication vs Authorization

This distinction is important for both implementation and testing. A missing or invalid token is an authentication problem. A valid token with insufficient permission is an authorization problem. If a tester uses an invalid token to test role restriction, the test is not proving authorization. To test authorization, use a valid low-privilege identity and attempt a restricted operation.

A user can be properly authenticated and still be improperly authorized. For example, an employee may log in successfully and receive a valid token. That token proves identity, but it does not mean the employee can delete users, export payroll data, approve refunds, or view another employee's private records. The API must perform permission checks after authentication.

Why Authorization Is Important

Authorization ensures that users can access only the resources and functions they are permitted to use. It protects sensitive data, business rules, workflow integrity, role boundaries, tenant separation, and high-risk operations. Without authorization, every authenticated account may become more powerful than intended.

Authorization protects confidentiality by preventing users from viewing data they should not see. It protects integrity by preventing unauthorized modification or deletion. It protects business workflows by ensuring that only approved roles can perform actions such as refunding payments, approving expenses, changing account limits, publishing content, or managing users. It also supports compliance because many regulations require access to sensitive data to be limited and auditable.

Broken Authorization can create privilege escalation. Horizontal privilege escalation happens when a user accesses another user's data at the same privilege level. Vertical privilege escalation happens when a user gains access to higher-level functions, such as employee to admin. Both are serious, and both are common in APIs when backend checks are incomplete.

Authorization Workflow

A normal authorization workflow begins after login. The user authenticates, the system identifies the user, and the API receives a request. The API then checks whether the user's role, permission, scope, policy, ownership, tenant, or attributes allow the requested action on the requested resource. If the rule allows the action, access is granted. If not, access is denied.

User Login
  |
Authentication
  |
Permission Check
  |
Access Granted or Denied

Good authorization is not a single check at login time. It must happen for each protected operation. A user may be allowed to read one resource but not another. A user may be allowed to read a record but not update it. A user may be allowed to update a profile name but not salary, role, or account status. Because API access is action-specific and resource-specific, permission checks need to be close to the backend operation being protected.

Common Causes of Broken Authorization

One common cause is missing permission checks. A developer may add a new endpoint and assume that authentication middleware is enough. The endpoint rejects anonymous users but does not verify roles, scopes, or ownership. This creates an API that is private but still over-permissive for logged-in users.

Incorrect role validation is another cause. The API may check for a role but check the wrong role, use outdated role names, treat role text case inconsistently, or accept role data from an untrusted source. Roles should come from trusted server-side data or validated token claims, not from client-submitted request fields.

Missing ownership validation creates Broken Object Level Authorization. The API may verify that a user is logged in but fail to confirm that the requested order, profile, ticket, document, account, or transaction belongs to that user. ID manipulation tests often expose this issue.

Trusting client-side data is also dangerous. A frontend may send `role: "Admin"` or `userId: 101` in the request body. The API should not trust these fields as proof of permission. Attackers can modify client requests. Authorization decisions must be made on the server using trusted identity, roles, scopes, policies, and ownership data.

Inconsistent authorization across endpoints is another common pattern. One endpoint may enforce permissions correctly, while another endpoint for the same resource forgets the check. For example, `GET /orders/{id}` may validate ownership, but `GET /orders/{id}/invoice` may not. Testers should examine related endpoints together, not as isolated happy paths.

Example: Unauthorized Delete

Consider an employee trying to delete an employee record:

DELETE /employees/101
Authorization: Bearer employeeToken

If only administrators can delete employee records, the API must deny this request. The expected response is commonly `403 Forbidden`. This is a function-level authorization check because delete is a privileged operation.

HTTP/1.1 403 Forbidden

If the API allows the delete operation because the employee is authenticated, authorization is broken. The backend must validate that the role or permission associated with the token allows the delete action on the employee resource.

Example: Accessing Another User's Data

Broken Object Level Authorization is one of the most common API authorization failures. Imagine User A is allowed to access personal profile `101`:

GET /users/101
Authorization: Bearer userAToken

User A then changes the URL to another ID:

GET /users/102
Authorization: Bearer userAToken

If the API returns User B's information, the API has a BOLA vulnerability. The API authenticated User A but failed to authorize access to object `102`. A secure API should verify object ownership, tenant membership, assignment, or another valid access rule before returning the data.

Example: Unauthorized Property Update

Property-level authorization failures happen when a user can read or modify fields that should be restricted. A regular employee may be allowed to update a display name or phone number, but not salary, role, credit limit, approval status, or account state.

{
  "name": "John",
  "salary": 120000,
  "role": "Admin"
}

If the API accepts the salary or role update from a regular employee, authorization is broken. Depending on design, the API may reject the request, ignore unauthorized fields, return a validation error, or return `403 Forbidden`. The key requirement is that restricted fields must not be modified by unauthorized users.

Example: Admin Endpoint Access

Administrative endpoints are common targets for authorization testing. A normal employee should not be able to call an endpoint such as:

POST /admin/createUser
Authorization: Bearer employeeToken

The expected response is commonly `403 Forbidden`. If the endpoint works for a non-admin user, the API has Broken Function Level Authorization. Admin paths, internal paths, export endpoints, configuration endpoints, and user-management endpoints should be tested with multiple roles.

Types of Broken Authorization

Broken Object Level Authorization occurs when users access specific resources that do not belong to them or are outside their allowed scope. Examples include viewing another customer's order, accessing another employee's profile, downloading another tenant's report, or modifying someone else's account settings.

Broken Function Level Authorization occurs when users execute operations reserved for higher privileges. Examples include delete, approve, refund, export, create admin user, change permissions, configure system settings, or perform batch operations. The problem is not the object alone but the function itself.

Broken Object Property Level Authorization occurs when users view or modify sensitive fields inside an otherwise accessible object. A user may access an employee profile but should not see salary. A customer may update a profile but should not update account status. A support agent may view an order but should not see full payment details.

These authorization types often overlap. For example, an employee updating another user's salary includes object ownership, function permission, and property-level permission. Strong testing separates the concerns clearly so failures can be diagnosed accurately.

Horizontal and Vertical Privilege Escalation

Horizontal privilege escalation happens when a user accesses another user's data while staying at the same privilege level. Employee A viewing Employee B's profile is horizontal escalation. Customer A viewing Customer B's order is another example. These issues are often caused by missing ownership or tenant checks.

Vertical privilege escalation happens when a lower-privilege user performs higher-privilege actions. An employee performing administrator functions, a customer approving refunds, or a guest accessing internal reports are examples. These issues are often caused by missing role, permission, or scope checks.

Both types must be tested. Horizontal escalation protects user-to-user boundaries. Vertical escalation protects role and authority boundaries. A secure API should prevent both, even when the request is technically well formed and includes a valid token.

Authorization Models

Role-Based Access Control, or RBAC, is one of the most common authorization models in enterprise APIs. Permissions are assigned to roles, and users receive permissions through role assignments. Roles such as Admin, Manager, Employee, Customer, Support Agent, and Guest are easy for business teams to understand and easy for testers to map into scenarios.

Attribute-Based Access Control, or ABAC, uses attributes to make decisions. Attributes may include department, region, clearance level, account type, resource owner, time, location, tenant, or record classification. ABAC is useful when access decisions depend on context rather than role alone.

Policy-Based Access Control, or PBAC, defines access through centralized policies. This helps large systems manage complex rules consistently. Resource-based authorization focuses on the relationship between the caller and the resource, such as owner, assignee, reviewer, team member, or tenant member.

The model matters less than enforcement. Whether the API uses RBAC, ABAC, PBAC, scopes, ownership rules, or a combination, the backend must validate permissions consistently for every protected operation.

Broken Authorization Risks

Broken Authorization can lead to data breaches, unauthorized modifications, privilege escalation, fraud, compliance violations, business logic abuse, and financial loss. A user who can access another customer's records may expose privacy data. A user who can modify restricted fields may alter salary, credit limits, discounts, or account status. A user who can call admin functions may create more privileged accounts or disable controls.

The risk is high because attackers can automate authorization abuse. Once they discover that changing an ID works, they can enumerate many records. Once they discover that an employee token can call an admin endpoint, they can repeat the action at scale. APIs are designed for structured, repeatable access, so a small authorization flaw can become a large incident quickly.

Broken Authorization in API Testing

API testers should verify role-based permissions, resource ownership, admin-only endpoints, user-specific resources, property-level restrictions, permission inheritance, horizontal privilege escalation, vertical privilege escalation, and least privilege enforcement. This requires more than a single valid token. Testers need identities for different roles and resource ownership states.

A good authorization suite includes positive tests and negative tests. Positive tests prove that authorized users can complete legitimate actions. Negative tests prove that unauthorized users are denied. For example, admin deletes employee should pass, employee deletes employee should fail, user views own profile should pass, user views another user's profile should fail, employee updates salary should fail, and guest accesses admin endpoint should fail.

Authorization tests should also cover related endpoints. If a resource can be viewed, exported, updated, deleted, approved, commented on, shared, or downloaded, each operation may need separate authorization rules. Do not assume that because one endpoint is protected, all companion endpoints are protected too.

Common HTTP Status Codes

Some APIs intentionally return `404 Not Found` instead of `403 Forbidden` to avoid revealing that a protected resource exists. This can be valid when documented and applied consistently. Testers should validate the expected contract and the security outcome: unauthorized users must not receive protected data or complete protected actions.

REST Assured Example

REST Assured can validate allowed and denied authorization behavior in Java API automation. An admin may be allowed to delete an employee record:

given()
    .header("Authorization", "Bearer " + adminToken)
.when()
    .delete("/employees/101")
.then()
    .statusCode(204);

The same action with an employee token should be denied:

given()
    .header("Authorization", "Bearer " + employeeToken)
.when()
    .delete("/employees/101")
.then()
    .statusCode(403);

For ownership testing, use two valid users. User A should access User A's resource but not User B's resource. This pattern is one of the most valuable ways to find BOLA defects.

Postman Example

In Postman, testers can create environments or variables for admin, manager, employee, customer, and guest tokens. The same endpoint can then be executed with different identities to verify whether the API returns the correct authorization response. This is useful for manually exploring permission matrices before automating them.

A Postman authorization collection can include admin endpoints, user-specific resources, object ownership checks, restricted field updates, guest access attempts, and cross-tenant scenarios. Test scripts can assert status codes and verify that sensitive fields are absent from denied responses. Real tokens should be handled carefully and should not be exported into shared files casually.

Karate Example

Karate can express authorization checks in a concise way. A permitted admin operation may look like this:

Given header Authorization = 'Bearer ' + adminToken
When method DELETE
Then status 204

A negative test with an employee token should expect denial:

Given header Authorization = 'Bearer ' + employeeToken
When method DELETE
Then status 403

Karate data tables can also drive multiple role and endpoint combinations. The important point is clarity. A failed report should clearly show which role, endpoint, action, and permission rule failed.

Real-World Examples

In banking, a customer may view personal accounts and transfer personal funds but must not access another customer's accounts. A bank employee may have limited operational permissions, while supervisors and administrators may have different controls. Authorization defects can expose financial data or allow unauthorized transactions.

In healthcare, a doctor may access assigned patient records but should not automatically access every patient in the hospital. A receptionist may schedule appointments but not view sensitive clinical notes. Authorization must reflect patient assignment, role, consent, and regulatory requirements.

In e-commerce, a customer may view personal orders but not another customer's order history. Support agents may view order details but may need restrictions around refunds, payment information, and account changes. Admin operations such as product deletion, coupon generation, and bulk exports require stronger controls.

In employee management systems, HR may update employee information, managers may view team members, employees may update only personal profile information, and payroll users may access salary fields. These differences require object-level, function-level, and property-level authorization checks.

Best Practices

Enforce authorization on every protected endpoint. Do not rely on frontend restrictions. The API should validate permissions on the server side for each operation. Validate resource ownership whenever a resource belongs to a user, account, organization, tenant, team, department, or project. Apply least privilege so each role receives only the access needed for its responsibility.

Use RBAC, ABAC, PBAC, scopes, resource ownership, or another suitable authorization model, but document the rules clearly. Never trust client-supplied role information or permission fields. Roles and permissions should come from trusted server-side logic, a validated token, an authorization service, or a reliable identity provider.

Test both positive and negative authorization scenarios. Include admin, manager, employee, customer, guest, and service accounts where applicable. Audit authorization failures safely. Logs should help teams investigate denied access without exposing secrets or sensitive data.

Common Mistakes

A common mistake is checking authentication but not authorization. A valid login does not automatically grant access to every resource. Another mistake is trusting client-side roles or user IDs. Attackers can modify request bodies, headers, cookies, local storage, and frontend state.

Missing ownership validation is one of the most damaging mistakes. APIs must verify that users can access only the resources they own or are authorized to access. Protecting only UI pages is also insufficient. Buttons, links, and menus can be hidden, but the API endpoint remains callable unless the backend checks permission.

Testing only administrator accounts creates false confidence. Admin users often have broad access, so admin-only tests rarely expose authorization gaps. Every supported role should be tested for allowed and denied operations.

Practical Authorization Test Strategy

A practical authorization test strategy starts with a permission matrix. The matrix should list resources, operations, roles, ownership rules, sensitive fields, and expected outcomes. For each endpoint, testers should know which users are allowed, which users are denied, and whether denial should return `403`, `404`, or another documented response.

Next, create test identities that represent real access levels. Do not use only one admin token. Use admin, manager, employee, guest, customer, tenant A user, tenant B user, owner, non-owner, and service account identities where relevant. Authorization tests become much clearer when the test data includes known relationships between users and resources.

Then test operations in pairs. If Admin can delete a record, verify that Employee cannot. If User A can view personal data, verify that User A cannot view User B's data. If Manager can update a team member, verify that Manager cannot update users outside the team. Every allowed rule should have at least one matching denied rule.

Finally, maintain authorization tests as the API grows. New endpoints, new roles, new fields, new reports, new exports, and new integrations can all introduce authorization gaps. Permission tests should be updated whenever the authorization model changes. Old assumptions should be reviewed regularly because stale permission rules are a common source of security weakness.

Designing Authorization Tests Around Real Business Rules

Authorization testing becomes stronger when it is connected to real business rules instead of only technical endpoint lists. A permission matrix is useful, but testers should also understand why each permission exists. For example, the rule "manager can view team members" is not the same as "manager can view every employee." The business meaning includes an ownership boundary: the manager's team. If the test checks only that a manager can call the employee API, it may miss the more important restriction that the manager must not access employees outside the team.

Good authorization tests therefore combine role, action, resource, and relationship. The role may be Manager. The action may be read, update, approve, export, or delete. The resource may be employee record, order, account, claim, report, document, or payment. The relationship may be owner, non-owner, assigned user, unassigned user, same tenant, different tenant, same department, different department, active customer, former customer, or guest. When these details are explicit, tests become much closer to real security behavior.

This approach is especially important in multi-tenant systems. A tenant is a customer, organization, company, or business unit whose data must be isolated from others. A user from Tenant A may have an admin role inside Tenant A, but that does not mean the user can administer Tenant B. Testing only role names is not enough because the same role can have different boundaries depending on tenant membership. Cross-tenant authorization tests should be part of any SaaS API validation strategy.

Field-level rules also need business context. A support agent may need to see order status and shipping details to help a customer, but may not need full payment data. A payroll user may view salary, while a general HR user may update address information but not compensation. A doctor may view clinical notes for assigned patients, while a receptionist may only see appointment schedules. These examples show that authorization often applies inside a response object, not only at the endpoint level.

Authorization tests should also account for state transitions. A user may edit a draft document but not an approved document. A customer may cancel an order before shipment but not after delivery. A manager may approve an expense before payment but not after it has been finalized. A tester who checks only static roles may miss these workflow-based permissions. Strong authorization testing includes role, ownership, resource state, and business timing.

Finally, authorization defects should be reported with precise context. A vague defect such as "authorization not working" is hard to fix. A useful defect says that an Employee role with token X can call `DELETE /employees/101`, or that User A can retrieve User B's order by changing the order ID, or that a Manager outside the department can update salary. Clear reporting helps developers find the missing rule quickly and helps security reviewers understand the impact.

Interview Questions

A common interview question is: what is Broken Authorization? A strong answer is that Broken Authorization is a vulnerability where authenticated users can access resources or perform actions beyond their assigned permissions. It happens after authentication and indicates that permission checks are missing, incorrect, or incomplete.

Another question is the difference between Broken Authentication and Broken Authorization. Broken Authentication allows attackers to bypass or compromise identity verification. Broken Authorization allows authenticated users to access resources or functions they should not access. Authentication failures commonly return `401 Unauthorized`; authorization failures commonly return `403 Forbidden`.

Interviewers may ask for examples. Good examples include accessing another user's data, calling administrator endpoints, updating restricted fields, deleting protected records, exporting reports without permission, and privilege escalation. They may also ask what testers should verify. The answer should include role-based access, resource ownership, function-level permissions, property-level restrictions, horizontal privilege escalation, vertical privilege escalation, and least privilege.

Interview-Ready Explanation

Broken Authorization is a security vulnerability where an API fails to verify whether an authenticated user has permission to access a resource or perform a specific action. The user may have a valid login or token, but the API allows operations beyond the user's role, ownership, scope, or permission level. This can lead to unauthorized data access, restricted field modification, admin function misuse, horizontal privilege escalation, and vertical privilege escalation.

Common forms include Broken Object Level Authorization, where users access objects belonging to other users; Broken Function Level Authorization, where users execute privileged operations; and Broken Object Property Level Authorization, where users read or modify restricted fields. These risks are represented in the OWASP API Security Top 10 because authorization failures are common and high impact.

During API testing, testers should use multiple valid identities and verify both allowed and denied actions. They should test roles, permissions, ownership, cross-user access, cross-tenant access, admin-only endpoints, property-level restrictions, and least privilege. Unauthorized operations should commonly return `403 Forbidden`, while missing or invalid authentication should return `401 Unauthorized`. The API must enforce authorization on the backend, regardless of what the user interface hides.

Key Takeaway

Broken Authorization proves why login alone is not enough. A user can be authenticated and still be restricted. Secure APIs must check what the user is allowed to do for each resource, function, field, and business operation. These checks must happen on the server side and must not depend only on hidden buttons, frontend routes, or client-supplied role values.

For testers, the practical rule is to test every important permission from both sides. Verify that authorized users can complete intended actions and that unauthorized users cannot access objects, functions, fields, or workflows beyond their permissions. Strong authorization testing protects data privacy, business integrity, role boundaries, and customer trust.