DEV Community

Jason Miller
Jason Miller

Posted on Originally published at axeploit.com

Your Scanner Solved the Login. It Never Solved the Logic.

#apiauth #dast #idor

Authenticated scanning is the most oversold line on a DAST feature checklist. Teams keep reading "the scanner can log in" as "the scanner covers what happens after the login," and the gap between those two claims is where your next incident report lives.

I've watched the loop repeat: upgrade to login-aware scanning, the authenticated crawl completes, the report comes back clean, and the first manual test finds a cross-tenant data read inside an hour. The scanner did its job. The job was smaller than the invoice suggested.

Login-aware scanning is plumbing

Strip the marketing and authenticated DAST is a replayed login script, session token capture and refresh, MFA handled with test accounts or seeded TOTP secrets, and a crawler that can finally see routes behind the auth wall.

That genuinely raises coverage. What doesn't change is the detection engine. It still evaluates one request at a time, still matches responses against known attack signatures, and still acts as a single identity. BrightSec's phrasing is blunt: DAST tests one request at a time and sees patterns it has seen before.

So a green authenticated scan means "no signature matched." Teams file it as "the workflows are safe." The tool never looked at a workflow. Even the login is only half covered, since SSO settings, OAuth and SAML wiring, and MFA policy sit outside both DAST runtime behavior and SAST code.

The bugs that only exist past the login

Skipped steps. Your checkout has one endpoint that validates the cart, one that applies the discount, one that takes payment. Each tests clean alone. Call the payment endpoint directly and the order goes through at the wrong price. The flaw is in the sequence, not in any single piece.

Two-user problems. The easy IDOR is a single-session object swap, and some scanners catch it. The expensive version needs two identities: user A's session pointed at user B's orders, a support role doing admin work, org one reading org two's invoices. Your scanner runs as one principal. It has no second identity and no written rule about who should see what.

Races and replays. A scanner fires requests serially. A flaw that only triggers when two requests land at the same instant, or the same payment lands twice, never fires. Every request is well-formed. There's no payload to signature.

The fix: test the workflow, not the request

Not a bigger scanner license. A small, separate pass built around intent. Start with abuse cases, statements of what must never happen in your highest-stakes workflows:

  • A payment must never complete for a cart not validated in this session.
  • A user must never approve a refund they requested.
  • One org's member must never read another org's object, even with a valid ID.

Scope by blast radius: anything that moves money or changes who can see what. For most apps that's three to five workflows, not fifty. Then test with two live sessions:

# TOKEN_A belongs to user A (org 1). Order 10042 belongs to user B (org 2).

# Baseline: A reads A's own order. Expect 200.
curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer $TOKEN_A" \
  https://api.example.com/orders/10007

# Cross-tenant: A asks for B's order. Expect 403 or 404. A 200 is a finding.
curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer $TOKEN_A" \
  https://api.example.com/orders/10042
Enter fullscreen mode Exit fullscreen mode

Per workflow, four moves minimum: skip a step, replay a step, swap two steps, execute a step as the wrong role. Hours, not weeks. And when your vendor says "we do IDOR detection," ask whether the test needs a second identity or a concurrency window. If yes, you're outside the engine.

What I'd actually do tomorrow:

  • Write "must never" abuse cases for your top three to five workflows before touching a proxy.
  • Run every authorization test with two live sessions, A's token against B's objects.
  • Four moves per workflow: skip, replay, reorder, wrong role.
  • Time-box one or two days per release cycle. A tester who knows one workflow's intended rules will outfind a scanner that knows every payload ever published.

What's the worst bug your authenticated scan signed off on that a human caught in the first hour? Cross-tenant reads feel like the universal answer, but prove me wrong.

Longer writeup if you want the full argument: https://axeploit.com/blog/your-scanner-solved-the-login-it-never-solved-the-logic

Top comments (0)