Sefism is free for learners. We are here to help you grow, one step at a time.Join for free
Sefism.
Security

Broken Object Level Authorization Tester for REST APIs That Runs in CI

Build a tester that reads an API's OpenAPI specification, logs in as two different users, and checks whether user B can read, change or delete user A's records by swapping IDs. Broken object level authorization tops the OWASP API Security Top 10, and it is easy to miss in code review. The tool runs on every pull request against a test environment and reports each leaking endpoint with the exact requests.

Topics
Difficulty

Advanced

Needs a team, real planning, and a supervisor who knows the area.
Effort

2 semesters · 2 students

Deliverables

7 to ship

4 optional extras

Suggested stack

Python or TypeScriptOpenAPI 3 parserDocker Compose test environmentsGitHub ActionsPostgreSQL for run historyOWASP crAPI or Juice Shop as targets
A suggestion, not a requirement. Swap anything for what you already know.

What you should ship

  • An OpenAPI reader that finds endpoints with object IDs in paths, queries or bodies
  • A producer and consumer analysis that learns which request creates an object and which ones use its ID
  • A two-user test runner: user A creates objects, user B tries every read, update and delete on them
  • A response comparison that separates real leaks from harmless differences such as timestamps
  • A pull request report listing each vulnerable endpoint with the reproducing request pair
  • A configuration file for roles, login flows and endpoints to skip
  • An evaluation on at least three deliberately vulnerable APIs and two real open source applications

If you have time left

  • Function level checks: a normal user calling admin-only endpoints
  • Support for GraphQL schemas as well as OpenAPI
  • Multi-tenant mode with users in two separate organisations
  • Learning the API from recorded traffic when no specification exists

The problem: one changed number shows someone else's data

A user opens /api/orders/1042 and sees their order. They change it to /api/orders/1041 and see a stranger's order, with name, address and phone number. This is broken object level authorization (BOLA, also called IDOR), and it is the first item on the OWASP API Security Top 10. It happens because the code checks that the user is logged in, but not that the record belongs to them.

The bug is boring to test by hand and easy to reintroduce. Every new endpoint needs the same check, and a missed one looks perfectly normal in code review. Startups building delivery, fintech and health apps in Pakistan and elsewhere ship new endpoints weekly, with no dedicated security tester.

What already exists and the gap

  • Autorize, a Burp Suite extension, replays a tester's traffic with a second user's session to spot authorization bugs. It needs a human driving the browser.
  • RESTler from Microsoft Research fuzzes REST APIs statefully from their specification, finding crashes and some security bugs, but authorization between users is not its focus.
  • Commercial API security platforms test for BOLA as part of paid suites.
  • OWASP ZAP scans web applications but does not reason about which user owns which object.

The gap is a free tool that runs unattended in CI, understands which requests create objects and which use them, and checks every endpoint with two real users on each pull request.

Inspiration

"Detecting Broken Object-Level Authorization Vulnerabilities in Database-Backed Applications" (BolaRay, ACM CCS 2024) combined SQL and static analysis to infer object ownership models, and found 193 vulnerabilities in 25 popular applications, 178 of them new. "RESTler: Stateful REST API Fuzzing" (ICSE 2019) showed how to infer producer and consumer dependencies between requests from a specification. This project combines RESTler's request sequencing with a black-box, two-user ownership check.

What you build

  • Developers add a GitHub Action and a config with two test accounts. Each pull request gets a check that fails if a new endpoint leaks.
  • Security reviewers get a report of each leak with the exact request pair, ready to paste into a terminal.
  • Students and trainers can run it against deliberately vulnerable APIs to learn the bug class.

The technically interesting part

  • Finding the objects. IDs appear in paths (/orders/{id}), query strings and request bodies. Use the specification plus naming patterns to find them, and learn producer and consumer links: POST /orders returns an id that GET /orders/{id} consumes.
  • Building valid requests. To test deletion you first need an object, which may need a customer, which needs an address. Order the requests correctly and fill required fields from schemas and examples.
  • Deciding what counts as a leak. A 200 with user A's data is a leak; a 200 with an empty list or a generic page is not. Compare user B's response with user A's using field-level similarity, and ignore volatile fields.
  • Login flows. Real APIs use cookies, bearer tokens, refresh tokens and sometimes one-time codes. Support a scripted login per role so the tester always holds fresh sessions for both users.
  • Side effects. Update and delete tests change data. Run against a disposable environment started with Docker Compose, and reset it between runs.

How to evaluate it

  • Known vulnerable targets: OWASP crAPI and Juice Shop have documented BOLA bugs; measure how many your tool finds without hints.
  • Injected bugs: remove ownership checks from a small clean API one at a time and record whether each is caught.
  • False alarms: run against two well-maintained open source APIs and judge each finding by hand.
  • CI cost: runtime per pull request, and how it grows with the number of endpoints.

Suggested plan

  • Weeks 1 to 3: study BOLA on crAPI by hand; parse an OpenAPI file and list ID-bearing endpoints.
  • Weeks 4 to 8: producer and consumer analysis and request generation.
  • Weeks 9 to 14: two-user runner, response comparison and the first report.
  • Second semester: GitHub Action, configuration, injected-bug evaluation, real applications and the write-up.

Path to a product

API security testing is a growing paid category, and small teams cannot afford the platforms. A free CI check focused on one bug class that does it well, with a hosted dashboard for organisations, is a familiar open-core shape. The evaluation is also strong evidence for application security roles.

Scope warning

Only test applications you own or that are built to be tested; never point the tool at a live third-party service. Support JSON REST APIs with an OpenAPI file first, and treat traffic learning and GraphQL as stretch goals.

Learn what you need on Sefism

Get help with this idea

The hard part is generating valid request sequences without hand-written scripts for every API. Tauseef can help you scope the producer and consumer analysis, pick evaluation targets and judge findings. If you are new here, create a free account first.

Ideas and guidance, not finished projects

These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.

Not sure this one fits you?

I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.

Discuss this idea
Work with me

Stuck on something specific?

Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.

Book a free sessionSee all services

Follow along

New writing, resources and project ideas land here first.