SUSPECTED A BREACH?  INCIDENT RESPONSE  contact@katitisecurity.com
VICTORIA +04MAHÉ · SEYCHELLES
APIsAttack surface7 min read

Your API is a map. Stop handing it out.

Before an attacker tries a single door, they want the floor plan. A modern application hands it to them through its API, in the form of documented endpoints, predictable patterns, and responses that carry far more than the screen ever shows.

01The API is the blueprint

A web page shows a user what the designer chose to show. The API behind it exposes the machinery. Every endpoint, parameter, and object is a labelled room on a map of how the application really works. Publish that map without protection and you have told an attacker exactly where value lives and how to ask for it.

This is not hypothetical. Public API documentation such as Swagger or WADL files, left reachable without authentication, has repeatedly given attackers a complete inventory of routes covering accounts, payments, and administration. The interface was never meant to be seen by an outsider. The API happily served it anyway.

02The endpoint that says too much

The second problem is over-sharing. An endpoint returns a user record, and the screen shows a name and an avatar. The raw response also carries an email, a phone number, a password-reset token, and an internal role flag. The interface hides them. The API does not. An attacker reads the response directly and takes everything in it.

Related to this is broken object-level authorization, where changing an identifier in a request returns someone else's data because the server never checked ownership. Combine over-sharing with weak authorization and no rate limiting, and an automated client can quietly harvest an entire user base.

The interface is not the security boundary. The server is. Anything the API will return, someone will eventually ask it for.

03What to lock down first

You do not need to solve everything at once. A short, ordered list closes most of the exposure.

  • Remove public documentation of private APIs. If an endpoint is not meant for the world, its map should not be either.
  • Enforce authorization on every endpoint and every object, on the server, for every request.
  • Return only the fields the client actually needs. Shape responses deliberately rather than dumping the whole record.
  • Rate-limit aggressively so that even a working endpoint cannot be harvested at scale.
  • Test the API as its own attack surface, not as an afterthought to the web front end.

APIs are now the primary attack surface for most modern applications. They deserve to be tested like it. A Katiti assessment treats your API as a first-class target, discovering documented and undocumented endpoints, checking authorization on each one, and proving where a response says more than it should.

// Get started

Turn this into an action list for your own systems.

A Katiti assessment finds where these ideas apply to you specifically, safely and with your authorization, and hands you a prioritised plan.