Authorization Deep Dive (IDOR / BOLA / BFLA)

Authentication answers: “Who are you?”
Authorization answers: “Are you allowed to do this to this data?”

In real incidents: IDORs happen when teams trust UI flows. The server needs to re-check ownership every time, even if it feels repetitive.

Why authorization bugs happen (deep reason)

• Developers confuse UI rules with backend rules: “The button is hidden” ≠ “the action is blocked”.
• AuthZ is scattered: some endpoints check ownership, others forget, especially new features.
• Object relationships are complex: nested objects (org → project → invoice) need consistent policy checks.
• Implicit trust in identifiers: assuming IDs in requests always belong to the caller.

Mental model: “who → what → which object → policy decision”

Every sensitive request must enforce:

• Principal: user/service identity (from server-validated session/token)
• Action: read/create/update/delete/approve/export
• Resource: the object being accessed (order #123, invoice #9)
• Policy: rules (owner can read, admin can export, support can view masked)

IDOR / BOLA (Broken Object Level Authorization)

What it is

When the server uses an object identifier from the request (path/query/body) but does not verify the caller is allowed to access that object.

Vulnerable pattern (example)

// Node/Express (example)
app.get("/api/orders/:id", async (req, res) => {
  const order = await db.orders.findById(req.params.id);
  // ❌ Missing ownership check
  res.json(order);
});

Secure pattern

// ✅ Enforce ownership in the query (best)
app.get("/api/orders/:id", async (req, res) => {
  const order = await db.orders.findOne({ id: req.params.id, ownerId: req.user.id });
  if (!order) return res.status(404).json({ error: "Not found" });
  res.json(order);
});

Testing methodology (systematic)

• Create two users: A and B.
• Let A create an object (order, ticket, document). Capture the request/response.
• Replay the same request as B using A’s object ID.
• Confirm not just the response, but any state change side effects.
• Repeat for nested objects: /orgs/{orgId}/projects/{projectId}/invoices/{invoiceId}

Fix recommendations (experienced answer)

• Centralize authorization policies (RBAC/ABAC).
• Enforce ownership checks at the data access layer (query filters / row-level security).
• Add automated tests for authZ matrix (role × endpoint × object).

BFLA (Broken Function Level Authorization)

What it is

Calling privileged actions (approve, export, admin changes) without role enforcement.

Vulnerable pattern

// ❌ Any authenticated user can approve refunds
app.post("/api/refunds/:id/approve", async (req, res) => {
  await refunds.approve(req.params.id);
  res.json({ ok: true });
});

Secure pattern

// ✅ Explicit policy check
app.post("/api/refunds/:id/approve", requireRole("finance_admin"), async (req, res) => {
  await refunds.approve(req.params.id);
  res.json({ ok: true });
});

Testing methodology

• Inventory privileged endpoints (admin routes, exports, approvals, role management).
• Try calling them with low-priv tokens (user, support).
• Check if the endpoint exists but UI hides it.

Fix

• Use a centralized authorization middleware/policy engine.
• Prefer deny-by-default; explicitly allow roles per action.
• Audit logs: who approved what, when, and from where.

Preventing regressions

• Add integration tests that assert forbidden actions return 403.
• Use “authorization matrix” test generation (role × endpoint).
• Code review rule: any endpoint touching data must show a policy check or constrained query.

Interview-ready answers (60-second + 2-minute)

60-second answer

Authorization is the server deciding who can do what to which resource. Bugs happen when APIs trust user-provided identifiers (IDOR/BOLA) or forget role checks on privileged actions (BFLA). The fix is consistent policy enforcement: query-level ownership checks, centralized authorization middleware/policies, deny-by-default, and regression tests for the role×endpoint matrix.

2-minute answer

I think of AuthZ as a policy decision applied to every request that touches data. The common failure mode is “UI rules” (hidden buttons) being mistaken for server rules. For object-level authorization, I enforce access at the data layer (e.g., WHERE id=? AND ownerId=?) so there’s no “fetch-then-check” mistake. For function-level authorization, I gate privileged routes (approve/export/admin actions) with explicit policy checks. I also cover tricky cases like nested resources (org→project→invoice), indirect references (shared links), multi-tenant scoping, and bulk endpoints. Finally I prevent regressions with automated tests for forbidden actions (403), policy centralization, and code review rules.

How authorization exploitation progresses (attacker mindset)

This is a real-world process explanation (no copy/paste exploit steps). Attackers don’t start with “dump data” — they start by proving inconsistent policy enforcement.

Phase 1: Inventory & classify endpoints

• Object access: “get/update/delete document/order/ticket by ID”.
• Privileged actions: approvals, exports, role changes, admin switches.
• Bulk endpoints: search, list, batch update, “include=details”.

Phase 2: Prove policy inconsistency

• Compare the same endpoint under two identities or two roles.
• Look for endpoints that return 200 where a sibling endpoint returns 403.
• Check “read vs write” paths separately — write paths are often less tested.

Phase 3: Expand scope via relationships

• Test nested objects (org/project/invoice) and indirect references (attachments, comments, exports).
• Test “child objects” where the server validates child ID but forgets to validate parent ownership.

Phase 4: Look for high-impact actions

• BOLA: access to another user’s resources (data exposure).
• BFLA: ability to trigger privileged actions (fraud/approval/export/role).
• Tenant escape: crossing organization boundaries in multi-tenant systems.

Tricky edge cases & bypass patterns (what attackers look for)

• Multi-tenant scoping bugs: object checks exist, but tenant boundary is missing (orgId not enforced).
• Indirect references: attachments, exports, “share links”, background jobs that fetch by ID without policy checks.
• Bulk endpoints: list/search/export endpoints returning data outside scope.
• Filter-based leaks: server validates access on detail endpoint but not on search filters.
• “Include” expansion: ?include=owner,notes,internal returning sensitive fields without re-checking policy.
• State transitions: endpoints that change status (approve/close/refund) without role checks.
• Concurrency: TOCTOU where access is checked, then resource is changed between check and use.

Safe validation workflow (defensive verification)

1. Baseline: capture the request for a resource owned by User A (or Role Admin).
2. Cross-identity test: repeat as User B (or lower role) using the same resource ID.
3. Confirm scope: verify not only response codes, but side effects (status changes, notifications, audit logs).
4. Relationship checks: repeat for nested resources (org → project → invoice) and indirect assets (attachments/exports).
5. Regression test idea: add an automated test asserting forbidden access returns 403.

Defensive patterns & fixes (Node.js)

Pattern 1: Query-level enforcement (best for BOLA)

// ✅ Ownership enforced in the query
app.get("/api/orders/:id", async (req, res) => {
  const order = await db.orders.findOne({ id: req.params.id, ownerId: req.user.id });
  if (!order) return res.status(404).json({ error: "Not found" });
  res.json(order);
});

Pattern 2: Central policy middleware (best for BFLA)

// ✅ Explicit policy check for privileged actions
function requireRole(role) {
  return (req, res, next) => {
    if (!req.user || req.user.role !== role) return res.status(403).json({ error: "Forbidden" });
    next();
  };
}

app.post("/api/refunds/:id/approve", requireRole("finance_admin"), async (req, res) => {
  await refunds.approve(req.params.id);
  res.json({ ok: true });
});

Confidence levels (how sure are you?)

• Low: suspicious inconsistency (different behavior across endpoints/roles) but not yet reproducible.
• Medium: reproducible cross-identity access difference with controlled scope (e.g., wrong row/scope).
• High: confirmed unauthorized access or unauthorized privileged action with clear evidence and minimal exposure.

Checklist (quick review)

• Every data-touching endpoint enforces policy (not UI rules).
• Ownership checks happen at the query/data layer where possible.
• Role checks protect approvals/exports/admin actions.
• Nested resources validate parent + child ownership/tenant scope.
• Bulk/search/export endpoints are scoped and tested.
• Automated tests cover role × endpoint × object matrix.
• Audit logs exist for privileged actions.

Remediation playbook

1. Contain: disable/guard the vulnerable endpoint or feature flag it.
2. Fix: implement centralized policy checks + query-level ownership filters.
3. Scope: search codebase for similar endpoints (same resource type, same pattern).
4. Test: add regression tests for forbidden cases (403).
5. Monitor: alert on unusual access patterns and privileged action usage.
6. Review: enforce code review policy: “show the authorization decision” for every endpoint.

Interview Questions & Answers (Easy → Hard)

Easy

1. AuthN vs AuthZ?
   A: AuthN is “who are you”; AuthZ is “are you allowed to do this to this resource?”.
2. What is IDOR/BOLA?
   A: When the server uses an object ID from the request but doesn’t verify the caller is allowed to access that object.
3. Why is “hiding a button” not a fix?
   A: UI is not enforcement. Attackers call APIs directly; the server must enforce policy.
4. Best primary fix for BOLA?
   A: Ownership enforcement at the query/data layer (scope by ownerId/tenantId).
5. Best primary fix for BFLA?
   A: Central policy checks/middleware with deny-by-default.
6. What HTTP code for forbidden?
   A: 403 for authenticated but not allowed; 401 when not authenticated.

Medium

1. How do you test for BOLA safely?
   A: Two identities. Create object as A, replay as B with the same ID, confirm response + side effects.
2. Where do these bugs hide most?
   A: Nested resources, bulk endpoints, exports, attachments, and admin tooling.
3. Why is “fetch then check” risky?
   A: Easy to forget checks; may leak fields before check. Query-level enforcement reduces exposure.
4. How do you handle multi-tenant scope?
   A: Every query must include tenant boundary (orgId/tenantId) in addition to ownership/role.
5. Follow-up: what’s your prevention strategy?
   A: Centralize authZ, add role×endpoint tests, and require visible policy checks in code review.
6. Follow-up: why not rely on frontend checks?
   A: Frontend is bypassable. Server must enforce.

Hard

1. Scenario: nested route checks child but not parent. Risk?
   A: Parent scoping bypass (org/project boundary). Fix by validating both parent and child belong to caller/tenant.
2. Scenario: export endpoint leaks fields not present in UI. Why common?
   A: Export paths are often built quickly and skip field-level policy checks. Fix: field allow-lists and policy per export.
3. Scenario: batch update accepts list of IDs. What’s the pitfall?
   A: Partial authorization—some IDs may be unauthorized. Fix: authorize each ID or constrain query to authorized set only.
4. Scenario: support role can “view” but not “export”. How enforce?
   A: Separate actions in policy (view vs export), enforce deny-by-default, audit exports.
5. Follow-up: what tests do you add after fixing?
   A: Integration tests asserting forbidden access is 403 across role×endpoint×resource combinations.
6. Follow-up: how do you keep policy consistent at scale?
   A: Central policy engine, code scanning for raw routes without checks, and shared data-access helpers.