A company admin can open another company’s orders

Change the id in the address and the API returns someone else’s order. Every screen looks right.

Company Admin

Why ordinary tests miss it

The list of orders is filtered by company, so every screen shows the right data. The endpoint for one order forgot the check. It only shows when someone tries an id that isn’t theirs, and the people who try are rarely your testers.

Set it up

Connect the API repository. The scan finds the endpoints, the records and the roles.
Run the access audit on the mock, and on acceptance once you verified its domain. Every role signs in and calls every endpoint with its own ids, with ids only other roles can see, and without a token.
Decide per finding: intended, or should be denied. The decisions become the project’s access policy, and the mock enforces them from then on.
After the fix, run the audit again, or add the call to a flow with a check that it is refused with 403, so it stays fixed.

The moment it’s caught

Access audit on Acceptance

✗ CriticalGET /api/orders/:id Company Admin can read another tenant’s data
Using an id from outside Company Admin’s scope, GET answered 200 instead of 403 or 404.
✓ Company AdminGET /api/orders Only their own company’s orders
✓ No tokenGET /api/orders/:id Refused with 401

An example of what you see, in Journey Lanes’ own words. The numbers and names are made up.

The finding names the role, the call and what came back. On live environments the audit never sends deletes, and only tries writes where you allowed them.

What you use

Next case: Ordering slows to a crawl when everyone orders at once

Catch this one in your own product

Connect a repository, describe the journey, and run it against the mock in a few minutes.