How to fix BOLA / IDOR

What an attacker can do

The concrete impact of leaving BOLA unpatched.

How to fix BOLA

6 ordered steps. Apply them in order — each builds on the previous.

1. 1

   Identify every endpoint that accepts an object identifier

   Enumerate every route that takes an :id, :uuid, :slug or similar URL parameter — this is your BOLA attack surface.

   Use your routing config (Express app.get, FastAPI @router.get, Rails routes.rb, Spring @RequestMapping) as the source of truth. List every route with a path parameter. For each, identify what database object it loads. This is your candidate list — every one of these needs an ownership check.

2. 2

   Add authorization check INSIDE the database query

   Filter by user_id (or org_id, tenant_id) directly in the WHERE clause, not as a post-query check.

   The naive fix is to load the object then check ownership. That's vulnerable to TOCTOU bugs and unnecessarily expensive. The correct pattern: include the user/org/tenant ID in the WHERE clause so the query returns null for objects the user doesn't own. This makes BOLA a 404 instead of a vulnerability.

   TypeScript / PrismaStep 2

   // VULNERABLE — naive lookup
   app.get('/api/orders/:id', async (req, res) => {
     const order = await prisma.order.findUnique({
       where: { id: req.params.id },
     });
     res.json(order); // returns ANY user's order
   });
   
   // SECURE — ownership in the query
   app.get('/api/orders/:id', requireAuth, async (req, res) => {
     const order = await prisma.order.findFirst({
       where: {
         id: req.params.id,
         userId: req.user.id, // <-- ownership check
       },
     });
     if (!order) return res.status(404).end();
     res.json(order);
   });

3. 3

   Use random / unguessable object IDs (UUID, ULID)

   Sequential integer IDs make BOLA enumeration trivial. UUIDs and ULIDs add defense in depth.

   This is NOT a substitute for ownership checks — UUIDs leak through email addresses, referer headers, server logs and shared links all the time. But sequential IDs let an attacker dump 'IDs 1 to 100,000' in a script. UUIDs reduce that to 'guess a 122-bit number', which is computationally infeasible. The combination of UUIDs + ownership checks makes BOLA exploitation an order of magnitude harder.

   PostgreSQLStep 3

   -- Migrate sequential IDs to UUID v7 (time-ordered, sortable)
   ALTER TABLE orders ADD COLUMN public_id UUID DEFAULT gen_random_uuid();
   CREATE UNIQUE INDEX orders_public_id_idx ON orders(public_id);
   
   -- Use public_id in URLs, keep internal id for FK joins
   SELECT * FROM orders WHERE public_id = $1 AND user_id = $2;

4. 4

   Add a centralized authorization layer (policy / guard)

   Don't write ownership logic per route — extract it into a policy class or middleware that every route uses.

   Per-route auth checks rot. A new endpoint gets added, the developer forgets the check, and you have a regression. The fix is centralization: a policy object (e.g. Pundit in Rails, CASL in JS, oso in Python/Go) that every endpoint calls before returning data. Policies are easier to audit and test than scattered if-statements.

   Python / FastAPI + casbinStep 4

   from casbin import SyncedEnforcer
   
   enforcer = SyncedEnforcer("policy.conf", "policy.csv")
   
   def authorize(user_id: str, obj: str, act: str):
       if not enforcer.enforce(user_id, obj, act):
           raise HTTPException(status_code=403)
   
   @router.get("/orders/{order_id}")
   async def get_order(order_id: str, user: User = Depends(current_user)):
       authorize(user.id, f"order:{order_id}", "read")
       return await db.order.find_one({"_id": order_id})

5. 5

   Cover BFLA at the same time — function-level authorization

   Same fix logic, applied at the route/function level. POST /api/admin/* should reject non-admins at the middleware layer.

   BFLA is BOLA's cousin: the request hits a function the user isn't authorized to call (vs. an object). Group your routes by required role at the router level — admin routes go through an adminMiddleware that rejects non-admins before any handler runs. This catches BFLA before the handler can leak data.

   ExpressStep 5

   // Middleware factory
   function requireRole(role: 'admin' | 'manager' | 'user') {
     return (req, res, next) => {
       if (!req.user || !req.user.roles.includes(role)) {
         return res.status(403).json({ error: 'Forbidden' });
       }
       next();
     };
   }
   
   // Group admin routes — every one inherits the check
   const adminRouter = express.Router();
   adminRouter.use(requireRole('admin'));
   adminRouter.post('/users/invite', inviteHandler);
   adminRouter.delete('/users/:id', deleteUserHandler);
   
   app.use('/api/admin', adminRouter);

6. 6

   Add unit + integration tests for cross-account access

   Every endpoint that loads an object needs at least one test asserting User A cannot access User B's object.

   Tests are how you prevent regression. Pattern: in your test setup, create two users (A and B) and an object owned by A. Then attempt to access A's object as B. Assert 404 or 403 — never the object itself. Run these on every PR. CI catches the day a developer 'temporarily disables' the ownership check for debugging and forgets to put it back.

   TypeScript / JestStep 6

   describe('GET /api/orders/:id — BOLA prevention', () => {
     let userA, userB, orderA;
   
     beforeEach(async () => {
       userA = await createUser();
       userB = await createUser();
       orderA = await createOrder({ userId: userA.id });
     });
   
     it('returns the order to its owner', async () => {
       const res = await api.get(`/orders/${orderA.id}`)
         .set('Cookie', sessionFor(userA));
       expect(res.status).toBe(200);
       expect(res.body.id).toBe(orderA.id);
     });
   
     it('returns 404 to a different user (NOT 403 or 200)', async () => {
       const res = await api.get(`/orders/${orderA.id}`)
         .set('Cookie', sessionFor(userB));
       expect(res.status).toBe(404);
       expect(res.body).not.toHaveProperty('id');
     });
   });