How to Automate CI/CD BOLA Checks: API Security Without the Fluff
Master CI/CD BOLA Checks Automation. Learn why traditional scanners fail and how to implement identity-aware testing in your GitHub Actions pipeline.

Broken Object Level Authorization (BOLA)—the artist formerly known as IDOR—consistently ranks as the #1 API threat on the OWASP Top 10.
But here is the problem: Your standard security scanners can't see it.
SAST tools look at code text, and DAST tools look for "bad characters." Neither of them understands the logic of who owns what data in your database. To catch BOLA, you need identity-aware automation in your CI/CD pipeline.
Why BOLA is the #1 Threat in 2025
Modern apps are built on microservices that pass around IDs for everything. If a user can access their own profile at /users/101 but finds they can also access someone else's sensitive data by changing the ID to /users/102, that’s BOLA.
It’s not a "hack" in the traditional sense; it’s a system doing exactly what the code says (return an ID) without checking if the requester has the right to see it.
The Problem: Traditional Tools are Blind
- Static Analysis (SAST): Sees
db.orders.find({ id: params.id }). It doesn't know thatownerIdis missing from the query. - Legacy DAST: Crawls for input fields to inject
' OR 1=1. It doesn't know "User A" shouldn't see "User B's" data because it doesn't understand identity.
The Strategy: Shifting BOLA Checks Left
The most effective way to automate BOLA checks is Two-User Cross-Testing.
- Identity Orchestration: Your CI system spins up two test users (A and B).
- Resource Discovery: User A creates a resource (e.g., an invoice).
- Cross-Check: User B attempts to access User A's invoice ID using User B's own valid token.
- Verification: The pipeline fails if User B receives anything other than a
403 Forbiddenor404 Not Found.
Implementing BOLA Checks in GitHub Actions
You can trigger a security scan on every Pull Request. This ensures no new BOLA vulnerabilities reach production.
name: API Security Scan
on: [pull_request]
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Start API
run: npm start & sleep 10
- name: Run BOLA Tester
run: |
npx bola-tester --url http://localhost:8080 --users ./test-users.json
Best Practices for High-Performance Teams
- Use UUIDs: Sequential IDs (
1, 2, 3) are trivial to guess and scrape. Moving to UUIDs makes enumeration attacks significantly harder. - Authorization at the Query Level: Don't just
findById(id). Use a pattern likefindOne({ id, ownerId: user.id }). By making the check part of the query, you eliminate "forgetting" theifstatement. - Tiered Scans: Run "Light Scans" (critical endpoints) on every PR and "Full Scans" nightly to avoid slowing down developers.
Quick Takeaways
- BOLA Targets Logic: Standard firewalls and linters won't save you.
- Cross-User Testing: This is the only way to reliably automate BOLA detection.
- Shift-Left: Finding a bug in a PR costs minutes; finding it in production costs thousands (and your reputation).
- AskCodi: Use AskCodi to generate the integration tests for your most sensitive endpoints in seconds.
One Action Item
Identify your most sensitive API endpoint today—the one that handles billing, PII, or internal settings. Write a single "Two-User" integration test for it and add it to your CI pipeline.
Don't wait for a manual audit to find what a simple script could have caught in 10 seconds.


