APIs, GraphQL and application logic
The bugs that live between endpoints rather than inside one: object references, mass assignment, over-broad queries, and workflows that can be run out of order.
By the end you can
- Enumerate an API's real surface from a specification, a client bundle, or introspection
- Test an object reference for authorisation rather than for existence, using two accounts
- Find a mass-assignment field by diffing what the API returns against what it accepts
- Query a GraphQL schema for the fields the UI never asks for, and measure the cost of a nested query
- Model a multi-step workflow as a state machine and find the transition nobody guards
- Write a logic bug up in terms of the assumption it breaks, not the request that broke it
1. Read
Hacking APIs: the bugs that live between endpoints
Modern web challenges are increasingly a REST or GraphQL API and a token. The four vulnerabilities that dominate API CTF - broken object-level auth, broken function-level auth, mass assignment, and GraphQL introspection - and how to test each one.
Thinking like the designer: finding the intended flaw
The hardest CTF challenges have no memory-corruption and no injection - just a system whose logic can be bent. Threat modeling from the attacker's chair: trust boundaries, assumptions, and the questions that find a logic bug.
2. Use the tools
In the order they come up while solving. Read what each one does, or go straight to the workspace tab that runs it.
- HTTP request replayer
Craft and replay HTTP requests with arbitrary methods, headers, and bodies, and read the raw response - a Repeater that runs in your browser.
Open it in the workspace - JWT decoder and signature verifier
Decode a JSON Web Token’s header and payload and verify HS256/HS384/HS512 signatures against a known secret - all locally.
Open it in the workspace - Web attack payload catalog
Curated payloads for SQL injection, XSS, SSTI, SSRF, GraphQL, and deserialization, organised by what you are trying to establish.
Open it in the workspace - Docker image inspector: layers, history and deleted secrets
Open a `docker save` tarball and read what a later layer only pretended to delete - plus the build history, which records every RUN command verbatim.
Open it in the workspace - HTTP security header analyzer
Analyse CSP, HSTS, X-Frame-Options, and CORS headers on a response - and find the gaps in a Content-Security-Policy that make XSS exploitable.
Open it in the workspace - Regex tester with match offsets and capture groups
Test regular expressions live against sample text, with every match’s offset, capture groups, and named groups broken out.
Open it in the workspace
3. Try one now
Generated in your browser and checked in your browser. No account, nothing to download, and a fresh one whenever you want another.
4. Practise on the real thing
Real picoCTF challenges that use these techniques, easiest first. 19 match in total - see the full index.
Common mistakes
The wrong turns this topic reliably produces. Written as the mistake rather than the rule, because the rule is easy to agree with and easy to walk straight past.
- Reporting an IDOR from one account. Without a second principal you have proved that an object exists, not that you were not entitled to it.
- Assuming the documented API is the API. Older versions, internal hosts and undocumented parameters routinely outlive the docs that describe them.
- Looking for injection in a logic challenge. If every request is individually valid, the bug is in the order, the quantity, or the state - not in the parsing.
- Testing GraphQL only through the queries the UI issues. Introspection, aliases and batched operations reach fields, and rate-limit behaviour, that the client never exercises, and that is where the authorisation gaps sit.
- Assuming a negative quantity, a zero, or an absurdly large one will be rejected because the form will not accept it. The browser's constraint is not the server's, and those are exactly the values at which a workflow's arithmetic stops holding.
Checkpoint
Against a multi-step workflow, complete it in an order the designer did not intend and state precisely which check assumed the previous step had happened.
Teaching note
Logic bugs are the hardest to teach because there is no payload to memorise. The reliable exercise is to make students write down the intended flow first, in five lines, and then attack their own diagram - the gap between the diagram and the implementation is where every finding comes from.
Go deeper
The lessons above are written to get you through a challenge. These go after the subject instead. Each one opens our notes on that chapter - what it argues, what to take from it and where it stops - so this is somewhere to read now rather than a book to buy first. Nothing here is affiliate-linked or sold by us.
Chapter 3, Common API Vulnerabilities
Hacking APIs - Corey Ball
The API-specific bug classes named and separated, which stops everything being called 'an IDOR'.
Chapter 11, Mass Assignment
Hacking APIs - Corey Ball
The diff-based method for finding assignable fields, which generalises well beyond APIs.
Chapter 14, Attacking GraphQL
Hacking APIs - Corey Ball
Introspection, query depth and batching - the three things that make GraphQL its own surface.
Chapter 18, Application Logic and Configuration Vulnerabilities
Real-World Bug Hunting - Peter Yaworski
The closest thing to a worked corpus of logic bugs, each with the assumption that failed.
Chapter 6, Secure Design
Designing Secure Software - Loren Kohnfelder
Read it from the other side: the design decisions listed here are the ones a logic bug is a failure of.
Every book the curriculum cites has a page in the library.