← All case studies
B2B SaaSAPI Security4 min read

The SaaS With More APIs Than It Knew

A fast-growing B2B SaaS discovered its real API surface and blocked cross-tenant (BOLA) access a scanner never caught.

Illustrative scenario, not a named customer. The behavior described is exactly how Nemesis Shield works.

The situation

A B2B SaaS ships fast. Two years of "just add an endpoint" left them with an API surface nobody could fully enumerate: internal routes that quietly became reachable, a deprecated v1 still serving traffic, debug handlers behind feature flags that weren't quite off. Their scanner tested the endpoints in their OpenAPI spec — but the spec was aspirational, and the dangerous routes were the ones not in it.

Their real worry was broken object-level authorization: multi-tenant data, object IDs in URLs, and no systematic guarantee that tenant A could never fetch tenant B's object. It's the #1 item on the OWASP API Top 10 precisely because it's invisible to tools that don't understand your data model.

What they did

They added the Sentinel SDK to their API — one middleware — and let API Security build an inventory from real traffic.

flowchart LR
  T["Live API traffic"] --> INV["Inventory<br/>every route + method + auth"]
  INV --> CL["Classify<br/>PII · PCI · Credentials"]
  CL --> RISK["Risk score<br/>unauth × sensitive × findings"]
  RISK --> ENF["Enforce<br/>off-baseline = blocked"]

Within a day the inventory showed them endpoints they'd forgotten existed — the live v1, two internal routes reachable from the internet, and a handful of unauthenticated endpoints touching PII. The risk view sorted the unauthenticated-and-sensitive ones straight to the top.

What changed

They fixed the obvious exposure (auth on the routes that needed it, retiring the zombie v1). Then they turned on enforcement.

The payoff was the BOLA case. Because API Security had learned that GET /accounts/{id}/… was only ever called by the account's own authenticated members, a test request for another tenant's account ID produced a request shape outside that route's baseline — and it was blocked in-process, with a finding naming the route and the shape. No rule had to be hand-written for it; the baseline was the rule.

Why it fit their business

  • The inventory is the traffic. No spec to write and keep in sync — they finally saw what their API actually exposes.
  • BOLA without a data-model integration. The learned per-route baseline caught cross-tenant access that a generic scanner structurally cannot.
  • One tool, not three. The same SDK and console that protects the app does discovery, classification, and enforcement — nothing new to buy or staff.

The generalizable point: you can't secure an API surface you can't see, and the most damaging API bug — one tenant reaching another's data — is exactly the kind that only a model of your normal will catch.

More scenarios