Sign in · Variablee Code · AI vulnerability detection for large codebases

96% recallof known BOLAs caught

97% precision rate1/28 false positives rate on industry benchmarks

4real-world apps with published BOLAs, from CVEs to OWASP targets

9frameworks across Ruby, Python and JavaScript / TypeScript

Benchmark: OWASP RailsGoat, OWASP crAPI, dvws-node and aegra (CVE-2026-44504). See the full results →

🧩

1. Parse

Indexes every method and class across Ruby, Python and JS / TS, and finds every route in Rails, Django, FastAPI, Express, NestJS and more.

✂️

2. Slice

Follows each route through its auth filters, middleware and guards into the handler and the calls that read or write data, and packs that path into its own context slice.

🧠

3. Reason

A frontier model reviews each slice on its own: is the requested object tied to the current user? Every flag comes with evidence and a fix.

One route, one slice

Only the code that runs for this request goes to the model, in the order it runs:

GET /orders/:id → OrdersController#showroute
ApplicationController#authenticate_user!auth filter
OrdersController#showhandler
Order.find(params[:id])data access, not scoped to current_user

Because each slice is small and self-contained, the codebase's size doesn't limit the review: every route gets the model's full attention.

What a finding looks like

Example from the OWASP crAPI benchmark

Every flagged route comes with a score, the object at risk, the exact data-access call, the checks that did run, file-and-line evidence, and a concrete fix.

GET /workshop/api/mechanic/mechanic_reportlikely

GetReportView#get · django

Fetches a ServiceRequest by an ID supplied in the query without verifying that it belongs to the requester, enabling access to others’ reports.

Object: query.report_id -> ServiceRequest
Data access: ServiceRequest.objects.filter(id=report_id).first()
Auth checks: jwt_auth_required (authentication only), no ownership check
Evidence: views.py:214-244; jwt.py:32-90

Fix: Authorize access by checking the ServiceRequest belongs to the authenticated mechanic/user before returning it.

The bug class

One ID swap away from someone else's data

A signed-in user changes an ID in the URL and gets another customer's invoice, order or account. Nothing crashes and no pattern matches: the bug is a permission check that isn't there. That's BOLA / IDOR, the #1 risk in the OWASP API Security Top 10.

Diagram: a caller-controlled invoice ID flows from the request through the controller and an ID-only lookup to the response, with no object-level permission check

Our method

One route at a time

We inventory every route, collect the shared middleware and the handler code that governs the object ID, and review access for that route alone. Then the next route, until the whole inventory is covered.

Three steps: inventory routes, collect route context (shared middleware, handler and calls), review access and flag a possible BOLA

Under the hood

A real context slice

This is the actual trace for one route: the handler, every call it makes with its file and lines, and the source of each filter on the way. That slice, and nothing else, is what the model reviews, so a large codebase never crowds out the code that matters.

JSON trace of GET /admin/users/:id: its handler, the calls it makes with file and line ranges, and the source of its before filter

What you get

Findings you can triage

Each candidate names the auth it passed, the check that's missing, nearby checks that hint at intent, and a concrete next step to confirm it, so your team spends time on real issues.

Illustrative scan output: three candidate BOLA findings, each with shared auth, the missing or unclear check, a nearby check, and a next step

From the lab

AI-native SAST for IDOR / BOLA The research behind Variablee Code, by Sella Rafaeli · Read the post →

AI SAST for The Enterprise