Broken Access Control (Deep Explanation)

1) Broken Access Control (Deep Explanation)

What it is Broken Access Control means the app does not properly enforce who can do what on which resource. Even if a user is logged in, they may be able to access data/actions outside their permissions.

Core concept Authentication answers: “Who are you?” Authorization answers: “Are you allowed to do this?” Broken Access Control is an authorization failure.

Common forms

1. Horizontal privilege escalation: user A can access user B’s data.
2. Vertical privilege escalation: normal user performs admin actions.
3. IDOR/BOLA: changing object IDs (e.g., /orders/1001 to /orders/1002) reveals others’ records.
4. Missing function-level checks: endpoint exists but role check is missing.
5. Forced browsing: accessing hidden URLs directly (/admin, /internal/reports).
6. Mass assignment: client can set protected fields like role=admin.

Real attack example

1. Attacker logs in as normal user.
2. Intercepts request: GET /api/invoices/4321.
3. Changes to GET /api/invoices/4322.
4. If server only checks “logged in” and not ownership, attacker reads other customer invoices.

Why it happens

1. Authorization checks are done only in UI, not server.
2. Checks are inconsistent across endpoints.
3. Developers trust client-sent fields (userId, role).
4. Complex role logic without central policy.
5. “Allow by default” behavior.

Impact

1. Data breach (PII, financial, health records).
2. Unauthorized actions (refunds, deletes, role changes).
3. Compliance violations (GDPR, HIPAA, PCI).
4. Loss of trust and legal/financial damage.

How to detect it

1. Test each endpoint with different roles and users.
2. Try ID tampering on every object-based API.
3. Verify server ignores client-provided authorization fields.
4. Add automated authorization tests in CI.
5. Use logs to detect unusual cross-tenant/resource access patterns.

Prevention (practical)

• action permission (can this role do this action?)
• object permission (does this user own/legally access this object?)

1. Deny by default for every route/action.
2. Enforce authorization server-side, never UI-only.
3. Centralize policy (RBAC/ABAC), avoid scattered custom checks.
4. Check both:
5. Use indirect references when possible (opaque IDs), but still enforce ownership checks.
6. Protect sensitive fields from mass assignment (role, isAdmin, accountBalance).
7. Add regression tests for every fixed access-control bug.

Secure pattern (conceptual)

• Insecure: if (isAuthenticated) return orderById(id)
• Secure: if (isAuthenticated && canReadOrder(user, id)) return orderById(id)