The traffic nobody watches

Open your product in a browser and you see a login screen, some buttons, a few forms. Behind that polished surface, your application is having a far busier conversation: dozens of API calls per page, mobile clients hitting the same endpoints, partner integrations pulling data on a schedule, internal services talking to each other. The UI is the part a human looks at. The API is the part an attacker looks at — and it's where most of the real traffic, and most of the real risk, actually lives.

The uncomfortable truth is that APIs get a fraction of the scrutiny the visible product gets. A login form gets pen-tested; the JSON endpoint behind it, hit a thousand times a minute, often ships with the authorization logic half-finished and the rate limits set to "infinite." For a lean team that's the dangerous gap: the breach you're most likely to suffer through an API isn't a clever zero-day, it's an endpoint that simply forgot to check whether this user is allowed to ask for that record.

The failures that actually cause API breaches

Industry breach data and the OWASP API Security project keep pointing at the same culprits, and almost none of them require sophistication to exploit:

  • Broken object-level authorization (BOLA). The endpoint authenticates you — it knows who you are — but never checks that the record you asked for is yours. Change /invoices/1041 to /invoices/1042 and you read someone else's data. This is consistently the single most common, most damaging API flaw, and it's a least-privilege failure expressed in code.
  • Broken function-level authorization. A regular user calls the admin-only endpoint and the server happily runs it because the check lived in the UI, not the API. The button was hidden; the route was wide open.
  • Excessive data exposure. The endpoint returns the whole object and trusts the client to display only some fields — so the password hash, the internal flags, and the other user's email ride along in the JSON, invisible in the UI but plain in the response.
  • No rate limiting or resource controls. Without throttling, one endpoint becomes a data-exfiltration firehose or a denial-of-service lever — and an unthrottled login endpoint is a credential-stuffing playground.
  • Unauthenticated or forgotten endpoints. The debug route, the old /v1 someone never decommissioned, the health check that leaks version strings — endpoints you forgot you shipped are part of your external attack surface whether you remember them or not.

A baseline a small team can actually hold

You don't need an API gateway with a six-figure license to close the common cases. You need a short set of disciplines applied to every endpoint, enforced in the one place attackers can't skip:

  • Authorize on the server, on every request, against the resource. Authentication answers "who are you"; authorization must answer "are you allowed this specific thing" — and it has to happen server-side, per object, every time. The UI hiding a button is not a control.
  • Return only what the client needs. Shape responses explicitly instead of serializing the whole database row. Default to omitting fields and add them deliberately, so a new sensitive column doesn't silently start leaking.
  • Rate-limit and size-limit everything. Throttle by user and by IP, cap page sizes, and reject oversized payloads. This is both an availability control — availability is a security property too — and a brake on bulk extraction.
  • Authenticate every endpoint, then inventory them. Every route is authenticated unless there's a written reason it isn't, and every route appears in an asset inventory of endpoints. You can't secure the API you forgot you deployed.
  • Validate input and version deliberately. Treat all input as hostile, and retire old API versions on a schedule instead of leaving /v1 running for years as an unguarded back door — the same change-management discipline you apply to anything else you ship.

Build it in, don't bolt it on

The cheapest place to fix an authorization bug is before it exists. API security belongs inside the secure SDLC, not in a frantic review the week of launch: authorization tests in the pipeline that assert user A cannot read user B's records, schema checks that catch over-broad responses, and a secrets-management discipline so API keys and tokens never land in code or get logged in plaintext. An endpoint without an authorization test is an endpoint you're hoping is correct.

It's also where your scanning meets reality. Vulnerability scanning finds the known-CVE problems in your API stack; only logic-aware testing — often a focused pen test — finds BOLA, because no scanner knows that invoice 1042 belongs to a different tenant. Knowing which tool finds which class of flaw keeps you from a false sense of safety.

Every finding is a tracked finding

When a review or a pen test surfaces an authorization gap, that's not a backlog nicety — it's a security finding with an owner and a clock, ranked by what it exposes. A BOLA flaw on an endpoint serving restricted customer data is a five-alarm fire; a verbose error message on an internal-only health check waits behind it. That's the same exposure-first triage that governs the rest of the program, pointed at the API layer, and tracked to closure under your remediation SLAs rather than living in a developer's memory.

Treat API authorization coverage as a measured dimension of your posture score: what fraction of endpoints have authorization tests, what fraction are rate-limited, how many forgotten routes turned up this quarter. Coverage drifts — a new endpoint ships without a test, an old version never gets retired — so it's a continuously verified number, not a one-time audit.

One honest caveat: a platform can track which of your endpoints have been reviewed and tested, organize the authorization findings a scan or pen test produces, route them to owners with deadlines, and keep that evidence current for an audit — it organizes, tracks, and proves the work. It does not write your authorization checks, test your APIs for you, make you compliant, or grant or guarantee any certification; the server-side checks, the rate limits, and the remediation are engineering work your team owns, and which regulatory obligations apply to your data is a question for counsel.

Your API is the front door your browser never renders, and it serves more traffic than your UI ever will. Most API breaches aren't exploits — they're missing checks: a record returned without asking whose it is, an admin route the UI merely hid. Authorize every request server-side, return only what's needed, throttle everything, and track every gap to closure. The boring baseline is the one that holds.