Broken Access Control.

It has ranked as the number one risk in the OWASP Top 10 for years. Security teams know about it. Developers have been warned about it. Frameworks and tools try to help prevent it. Yet it still appears in real-world attacks with alarming frequency.

Why?

Because the problem looks simple on the surface, but is very easy to get wrong in practice. One missing permission check. One place where the server trusts the client too much. One forgotten ownership validation. That’s often all it takes for an attacker to view or modify data they should never be able to reach.
In this article, we’ll break down:

• What is Broken Access Control

• How attackers exploit it in real scenarios

• What actually works when it comes to stopping it

No heavy theory. Just clear explanations and practical understanding.

What is Broken Access Control?

Broken Access Control is a security vulnerability where a web application fails to properly restrict what authenticated users are allowed to do. Because of this failure, attackers can access data or features that should be protected — such as viewing another user’s private information, modifying records they don’t own, or performing administrative actions without permission.

It has ranked as the number one risk in the OWASP Top 10 for several years due to how common and damaging it is.

In simple terms, access control is broken when a user can reach resources or actions they should not be able to access. This usually happens for one of two reasons:

1. No access check is performed The application does not verify whether the logged-in user has permission to access the requested data or function.

2. The access check is weak or poorly implemented Some verification exists, but it is incomplete, easy to bypass, or relies on untrusted information from the client.

How attackers exploit it in real scenarios

Example 1: Insecure Direct Object Reference (IDOR)

Many applications fetch data using identifiers such as user IDs, order IDs, or document IDs. For example:

GET /api/mails?user_id=1024

If the server returns the data without confirming that the currently logged-in user actually owns that mailbox, an attacker can simply change the ID to another value (for example, 1025) and read someone else’s emails.

This type of flaw is very common and can also appear in unprotected API endpoints, direct file links, cloud storage URLs, and directory listings.

For better understanding refer the following blog - Click.

Example 2: Trusting the client

Some applications incorrectly rely on the frontend to enforce permissions. The server might send a response like:

{
  "isAuthorized": false
}

If the application trusts this value, an attacker can intercept the response, change it to true, and gain access to restricted features.

Access control decisions must always be enforced on the server, never trusted from the browser or mobile app.

Example 3: Role or identity tampering

In systems that use roles, an attacker may try to modify request parameters such as:

{
  "role": "admin",
  "user_id": "123"
}

If the server blindly trusts the role or user identity sent by the client (instead of verifying it from a secure session or token), the attacker can escalate their privileges and access administrative functions or other users’ data.

Example 4: Bypassing OTP / verification steps

Some applications use a multi-step process for sensitive actions like password reset. The server sends an OTP to the user’s email or phone, and the client is expected to include that OTP in the next request.

An attacker can intercept the request and simply remove the OTP field (or leave it empty). If the server only checks whether “OTP verification was successful” using a flag, and does not properly validate that a correct OTP was actually provided in the current request, the attacker can skip the verification step entirely.

This allows them to reset the password of any user whose account they target. The root problem is that the server trusts a previous state or a client-controlled flag instead of re-validating the critical security step.

Example 5: Stale session / privilege revocation failure

Access control must be enforced continuously, not only at login time.

Consider this situation:

• User B is temporarily given Super Admin privileges by mistake.

• User B logs in and receives a session with admin rights.

• The mistake is noticed and User B’s role is changed back to a normal Analyst.

If the application does not invalidate or refresh the existing session, User B continues operating with Super Admin privileges until the session expires or they log out.

This is a classic Broken Access Control issue caused by stale authorization state. Permissions were correctly updated in the database, but the running session was never forced to re-evaluate them.

For better understanding refer the following blog - Click.

What actually works when it comes to stopping it

Effective mitigation requires moving all authorization decisions to the server and ensuring that every request is properly checked before sensitive data or actions are allowed.

1. Core Architectural Techniques

• Enforce Server-Side Authorization
  Never rely on hidden buttons or frontend logic. Every backend endpoint must check permissions itself.

// Bad: Only hiding the button in the UI
// Good:
if (currentUser.id !== resource.ownerId) {
  return res.status(403).json({ error: "Forbidden" });
}

• Implement Deny-by-Default
  Block everything unless an explicit rule allows it.

// Pseudocode
if (!policy.allows(currentUser, "read", resource)) {
  deny();
}

• Verify Record Ownership
  Always tie the requested resource to the logged-in user. This blocks IDOR attacks.

SELECT * FROM orders 
WHERE id = ? AND user_id = ?;

const order = await db.orders.findOne({
  id: requestedId,
  userId: currentUser.id
});
if (!order) return res.status(403).send("Forbidden");

• Centralize Authorization Logic
  Avoid repeating checks in every function. Use middleware or a shared authorization service.

// Express-style middleware example
function requireOwnership(req, res, next) {
  if (req.resource.ownerId !== req.user.id) {
    return res.status(403).send("Forbidden");
  }
  next();
}

• Use Proper Access Control Models

1. RBAC: Roles like admin, editor, viewer

2. ABAC / Relationship-based: Permissions based on ownership, team membership, sharing, etc. Example: Google Zenzibar / SpiceDB.

Example (relationship style):
User:Alice  is_owner  Document:42
→ Alice is allowed to edit Document 42

2. State, API, and Session Defenses

Secure Session and Token Handling
Use short-lived tokens and invalidate sessions when privileges change.

When a user’s role is downgraded:
→ Invalidate their current session/token
→ Force them to re-authenticate or refresh permissions

• Restrict CORS and Hide Sensitive Paths
  Only allow trusted frontend origins and disable directory listing.

Enforce Business Workflow Rules
Critical steps (like OTP verification) must be validated on the server every time, not trusted from the client.

// Bad: Trusting a client flag
if (req.body.otpVerified === true) { ... }

// Good: Re-validate the OTP server-side
if (!await verifyOTP(userId, req.body.otp)) {
  return res.status(403).send("Invalid OTP");
}

Another Helpful Mitigating Idea

Simple Ownership / State Check (for single-user management apps)

In applications where users are only supposed to manage their own data (for example personal profiles, private notes, or individual order history), a straightforward ownership rule works very well.

The idea is simple:

• Every resource is tied to a specific owner.

• When a request comes in, the server checks whether the logged-in user is the owner of the requested resource.

• If User A is logged in and tries to access a resource that belongs to User B, the transition User A → User B’s data is treated as invalid and rejected.

Example:

// Pseudocode
if (requestedResource.ownerId !== currentUser.id) {
  return deny("You can only access your own data");
}

Or at the database level:

SELECT * FROM documents 
WHERE id = ? AND owner_id = ?;

This approach is highly effective against common IDOR-style Broken Access Control bugs in simple applications.

Note: It works best when resources have a single clear owner. For systems that support sharing, teams, or multi-tenant access, a more advanced policy engine (relationship-based or attribute-based) is usually required.

Broken Access Control remains the most common and damaging web vulnerability because it is easy to overlook and hard to get completely right. One missing check is often all an attacker needs.

The good news is that the defenses are clear: enforce authorization on the server, verify ownership of every resource, apply deny-by-default, and make sure every path that can reach sensitive data actually performs the check.

If you take only one thing away from this article, let it be this — never trust the client, and never assume a permission check exists just because it should.

Secure access control is not optional. It is foundational!
Thanks for reading. I hope this helped you better understand Broken Access Control.✌️