Hacking APIs

Ball's argument is that application security advice was written for pages and applications stopped being pages. The interface is a client; the API is the application; and the authorisation logic that a page used to enforce by not rendering a button is now enforced, or not, by an endpoint that will answer anybody who asks it correctly.

For a competition that is a useful correction, because a growing share of web challenges have no interesting front end at all. What they have is a documented endpoint, an object identifier, and a check somebody wrote once and never applied to the second route.

Why it is on this shelf

It is the only book here that treats authorisation as a first-class subject rather than a paragraph inside access control. Object-level and function-level authorisation failures are the two most common API bugs in the world and among the most common in CTF web categories, and they are invisible to every scanner because a correct-looking 200 is exactly what they return.

Chapter 3, Common API Vulnerabilities

The taxonomy chapter, and the one to read first even if you read nothing else. It walks most of the OWASP API Security Top 10 and adds two the list leaves out: information disclosure and business logic flaws.

The information disclosure section is the most immediately usable. His example is a WordPress site serving its full user list from /wp-json/wp/v2/users to anybody who asks, which is not a misconfiguration so much as a default nobody looked at. The other half is verbose errors: an API that says the user does not exist for one address and the password is wrong for another has just told you which addresses are real. Both patterns show up constantly in challenges, and both are found by reading responses rather than by sending payloads.

The business-logic section is deliberately vague, and honestly so - logic flaws are by definition the ones no list can enumerate. What he gives you instead is the question: what does this API assume the client will not do?

Chapter 6, Discovery

Passive then active. The passive half is search engines, code repositories, public API directories and the target's own documentation - and the documentation is the point. An API with published documentation has told you its object naming, its versioning scheme and its parameter names, which is most of what an attack needs.

The active half is endpoint enumeration, and the specific trick worth keeping is versioning: an application on /api/v2/ frequently still serves /api/v1/, and the old version is where the check is missing. Our attack-surface lesson covers the same ground for pages, and the directory scanner does the enumeration.

Chapter 8, Attacking Authentication

Basic auth, API keys, JWTs and the attacks against each: brute force, credential stuffing, password spraying, token forgery. The JWT material is competent and short - none-algorithm, weak signing secret, algorithm confusion between HMAC and RSA - and it is the section most likely to come up in a challenge.

Work it with the JWT decoder, the none-algorithm tool and the secret bruteforcer. JWT attacks here goes further into key confusion than the chapter does.

Chapter 10, Exploiting Authorization

Broken object-level authorisation and broken function-level authorisation, which sound like the same bug and are not. The first is asking for somebody else's object with your own valid credentials. The second is asking for an administrative function with an ordinary account - a different HTTP method on the same path, or an /admin route the interface never shows you.

The testing method requires two accounts, and this is the part people skip in a competition and then cannot prove anything. Create both, capture the same operation as each, and diff the requests: the identifier that differs is the one to swap. Everything else in this chapter follows from that one habit.

Chapter 11, Mass Assignment

A short chapter about one very high-value bug: an API that takes the client's JSON and binds all of it to a server-side object. His canonical example is a registration request with an extra field added - a role, or an admin flag - that the backend dutifully assigns because nobody wrote an allowlist.

The reason it is worth a chapter is that finding the field name is the whole difficulty. He suggests reading the documentation for fields returned but not accepted, reading the response body of a GET on the same object, and fuzzing parameter names. In a challenge the answer is nearly always visible in a response you already have: whatever the object shows you, try sending back.

Chapter 12, Injection

The injection classes as they appear through an API rather than a form: SQL and NoSQL, operating system command injection, and cross-site scripting delivered through a JSON field that some other client will render. His point is that API input often skips the validation the web form had, because the form was where somebody remembered to put it.

The NoSQL material is the part CTFs use most - operator injection where a string parameter is replaced by an object - and injection beyond SQL carries it further. For the classical case, SQL injection in CTF and the request replayer are the working pair.

Chapter 14, Attacking GraphQL

The chapter that earns the book a place on a CTF shelf, because GraphQL challenges are common and almost nothing else here covers them. One endpoint, one POST, a query language on the other side, and a type system that will describe itself to you if introspection is enabled.

The method is: introspect, read the schema, and look for the query or mutation the interface never calls. When introspection is disabled, field suggestion in error messages usually leaks the schema anyway, one guess at a time. He also covers batching, which is both a rate-limit bypass and a way to run an authorisation test hundreds of times in one request.

Hacking APIs in CTF is the local version of this chapter and includes the introspection query itself.

Where it stops

It is a lab-and-tooling book, and the labs are its own vulnerable applications. Roughly a third of it is setup, Burp configuration and scanning, none of which you need for a challenge that hands you a URL. The tool-specific instructions have aged the way tool-specific instructions do.

It also stops at the boundary of the API. When an authorisation bypass gets you to a file-read endpoint or a template, the next move is in Bug Bounty Bootcamp or Designing Secure Software, not here.

What to take into a challenge

Two accounts and a diff. Almost every authorisation bug in this book is found by performing the same operation as two different principals and comparing the requests, and it is a technique that costs nothing and works on APIs, web applications and any challenge with a login. Where the challenge gives you one account, the second principal is the one whose identifier you found in a response.