How to hack APIs in 2026

Five years is a long time in API security

Back in 2021 I wrote a guide on hacking APIs with Farah Hawa. It did well, partly because at that time APIs had become hugely popular in the development world while most cybersecurity content still assumed you were poking at a server-rendered web app. The shift from server rendered to client-side + API is well and truly done now. In 2026 the API is the application for most of what you’ll test. The browser, the mobile app, the smart TV, the partner integration, the AI agent calling a tool, they’re all just clients talking to the same handful of endpoints behind the scenes.

So this is the 2026 update. A lot of what we said in 2021 still holds, and we’ll say it again here so you don’t need to go digging through the old post. But the attack surface has grown teeth in a few new places: GraphQL is everywhere now, OAuth flows have gotten more elaborate and more misconfigured, and a whole class of AI-backed APIs has appeared that didn’t exist when we last wrote this. Let’s get into it.

What actually is an API, and why they break

An API (Application Programming Interface) is just a contract for how two pieces of software talk to each other over the network. In web security terms, when you open a modern app and it loads your data without a full page reload, that’s the frontend making background requests to an API and rendering whatever comes back. Most of these speak JSON over HTTP, though you’ll still meet XML, SOAP, gRPC and GraphQL in the wild.

The reason APIs are such fertile ground for hackers is because that’s exactly where the majority of sensitive data and functionality are accessible. You can call it directly, in any order, with any values you like, skipping every check the frontend was supposed to enforce. Almost every API bug in this guide comes back to that one gap between “how the app expects to be used” and “how it can actually be used.”

Setting up to test APIs

You don’t need much. An intercepting proxy and something to replay and craft requests will carry you most of the way.

• An intercepting proxy. Burp Suite is still the default. Caido has become a genuinely popular alternative since 2021 and is worth a look if Burp feels heavy. Either one sits between your client and the server so you can read, modify and replay every request.
• A request builder. Postman is still fine for importing a collection and firing requests. Bruno and Insomnia are lighter open-source options that have gained ground. Whatever you pick, wire its proxy setting to 127.0.0.1:8080 so traffic flows through Burp or Caido, and import the relevant SSL certs so that the traffic flows smoothly.
• Content discovery. I personally use ffuf and feroxbuster for fast fuzzing, and kiterunner when I specifically want API-aware route discovery, and the Assetnote wordlists (still the gold standard for API paths and parameter names).
• A note-taking habit. APIs have a lot of endpoints and a lot of state. Keep track of which tokens belong to which user, which IDs you’ve seen, and which endpoints you haven’t tried yet. APIs can be very complex, and the best bugs tend to come from systematically and diligently testing every single endpoint.

Step one: find the API and map it

Before you start hunting, build a picture of the whole API.

Read the Client-Side JavaScript

First things first, we read the client side JavaScript. Single page apps ship the map of their own backend in the client-side code. The frontend JS is full of endpoint paths, parameter names and sometimes even hardcoded keys 👀. Pull the JS, search it for /api/, fetch(, axios, and route fragments. AI assistance is enormously helpful here. A frontier like gpt-5.6-sol or claude-opus-5 at the time of writing combined with Claude Code or Codex in the terminal will be able to assist you in pulling down the client-side JS and analyzing to build a map of the API.

Proxy the Mobile App

Once you’ve done this, it also pays to proxy a mobile app, if there is one. Mobile clients often talk to richer or older API versions than the web app, and they’re a common source of undocumented endpoints. Route the app through your proxy and watch what it calls.

Find and Read the Documentation

Another great source for API mapping is the documentation. Swagger / OpenAPI specs, GraphQL schemas, Postman collections left public. A /swagger.json, /openapi.json or /api-docs hands you the entire map in one go.

Enumerate versions and non-prod routes

Old versions rarely get the same security attention as the current one. Try /api/v1/, /api/v2/, /api/beta/, and swap the host or path for non-production names: dev, qa, staging, test, uat, preprod, internal. A deprecated v1 endpoint that skips a check the v3 version added is a classic finding, and OWASP now tracks this under “Improper Inventory Management.”

GraphQL Introspection

If the target speaks GraphQL, try an introspection query. When introspection is left enabled (it often is), the server returns its entire schema: every type, query, mutation and field. That’s your whole map in one request. Tools like GraphW00f (fingerprinting) and InQL or graphql-cop (auditing) speed this up. Sometimes, even when introspection is disabled, you can still map the whole API by carefully looking at the error messages. Some GraphQL implementations give handy clues, for example if you query “user”, it responds “Did you mean users?”. You can use a tool like Clairvoyance to map out the entire API if this is the case.

The vulnerability classes worth your time

OWASP maintains a dedicated API Security Top 10 (the current edition is the 2023 list), and it’s a good backbone. We’ll walk the ones that actually pay off, explain each from scratch, and flag what’s changed since 2021.

1. Broken Object Level Authorization (BOLA / IDOR)

This is the big one. It was the big one in 2021 too, we just called it IDOR (Insecure Direct Object Reference) back then. I don’t know why the name changed. It remains number one on the OWASP API list, and it’s the single most valuable bug class to understand.

The idea is that the API has an endpoint with an identifier for some object, like GET /api/v1/invoices/1234, and returns that object without checking whether you are allowed to see it. Change 1234 to 1235 and if you get back someone else’s invoice, that’s BOLA (aka IDOR). The server authenticated you (it knows who you are) but never authorized the specific request (it didn’t check that this object is yours).

How to test it: create two accounts, do an action as user A, then replay A’s request using B’s token and A’s object ID. If B can read or modify A’s data, you’ve landed yourself a neat bug 👌. Watch for IDs everywhere. In paths, query strings, request bodies, headers, everywhere!

What’s changed since 2021: many developers wised up to sequential integer IDs and switched to UUIDs, thinking randomness equals security. It doesn’t. UUIDs are identifiers, not access controls, and the RFC itself says so. If you can obtain a UUID from anywhere (a shared link, a different endpoint that leaks it, a search result), the BOLA is still exploitable. Don’t skip an endpoint just because the IDs look unguessable.
One interesting point that most hackers (and devs) miss is that you can not assume that UUIDs are random. It even says so in the UUID RFC spec:

See for yourself here!

2. Broken authentication

Authentication is proving who you are. When it’s broken, you can become someone else, or nobody in particular, and still get in.

JWT Implementation Weaknesses

JSON Web Tokens are the standard way APIs carry identity. A JWT is three base64 chunks joined by dots: a header, a payload, and a signature (header.payload.signature). The header says which algorithm signs the token, the payload holds claims like your user ID, and the signature is what stops you from tampering with the payload. The classic attacks all still work in 2026 because people keep misconfiguring the libraries:

• alg: none. Set the algorithm to “none” and strip the signature. If the server honors it, it’s trusting an unsigned token, and you can put whatever you want in the payload.
• Weak secret. HS256 tokens are signed with a shared secret. If that secret is weak (secret, changeme, a leaked value), you can crack it offline with hashcat and then forge valid tokens for any user.
• RS256 to HS256 downgrade. RS256 uses a private key to sign and a public key to verify. If you switch the header to HS256 and sign the token with the server’s public key as the HMAC secret, a naive library will verify it, because it uses the same public key it hands out freely.
• Ignored expiry. Check whether an old token still works. Plenty of implementations never actually validate the exp claim, so tokens live forever.

I actually built a JWT Hacking toolkit which will assist you in running these tests and crafting the payloads, you can use it here: https://hakluke.com/jwt-hacking 

OAuth and OIDC misconfigurations 

These are newer, and everywhere all of a sudden. In 2021 we barely touched OAuth. In 2026 you’ll see it constantly. It’s very complex and therefore very easy to mess up. The first thing to check is open redirect_uri handling that lets you steal an authorization code, then check missing state parameters (CSRF on the login flow), and refresh tokens that don’t rotate or expire. A single sloppy redirect validation can hand you full account takeover 👌. You can learn more about the main attack types in the OAuth2 labs from Portswigger Web Security Academy

3. Broken Object Property Level Authorization (mass assignment + data exposure)

OWASP merged two 2021-era ideas here. Excessive data exposure is where the API returns more than is needed, including something that shouldn’t be exposed. For example, the app might intend to just display your name, but to do that it calls an endpoint that also includes “passwordResetToken”, “creditCardNumber” or some other PII in the JSON response . The frontend might not render those fields so it’s important to read the raw response, not the rendered page.

Mass assignment is the reverse problem. You send extra fields that the API blindly accepts. If updating your profile takes a JSON body with a name and email, try adding other fields that might be associated with the user like “role”: “admin” or “verified”: true and see if it sticks. Frameworks that auto-bind request bodies to database objects are especially prone to this (most modern frameworks do!).

4. Unrestricted resource consumption and race conditions

In 2021 we called the first part “lack of rate limiting” but “unlimited resource consumption” seems like a more fitting name because it covers quite a wide variety of vectors. A lack of rate limiting means you can brute-force credentials and OTPs, enumerate users, scrape data at speed, and rack up the target’s costs by hammering expensive endpoints (every SMS, email or LLM call an endpoint triggers is money spent). You can use tools lik Burp Intruder or ffuf to quickly check whether anything throttles you.

Race conditions are subtler and still underrated. If an endpoint checks a condition and then acts on it as two separate steps, firing many requests at once can slip between the check and the action. This concept is sometimes referred to as “TOCTOU” which stands for “time-of-check, time-of-use”. The textbook case is redeeming a one-time discount code or gift card a hundred times simultaneously before the “already used” flag is written. Burp’s built-in “send group in parallel” (single-packet attack) has made this far easier to test in 2026 than the Turbo Intruder scripts we used in 2021. If money or limited resources are involved, always test for it.

5. Broken Function Level Authorization

BOLA is about objects (can I see your invoice). This is about actions (can I call an admin function at all). Regular users often retain access to privileged endpoints simply because the UI hides the button rather than the server enforcing the permission.

Test it by taking an admin action, capturing the request, and replaying it with a low-privilege token. AI does this surprisingly well, if I do it manually I use the Burp extension called “Autorize” which swaps the tokens on all intercepted requests to make things easy.
Also try flipping the HTTP method: an endpoint might block GET /api/users for you but happily accept DELETE /api/users/5 or PUT. Swapping verbs (GET, POST, PUT, PATCH, DELETE) is a two-minute check that finds real bugs.

6. Server-Side Request Forgery (SSRF)

SSRF is when you get the server to make a request on your behalf to somewhere it shouldn’t. Any API parameter that takes a URL is a candidate: a “fetch image from URL” feature, a webhook config, a document importer. Point it at http://169.254.169.254/ (cloud metadata), http://localhost/admin, or internal hostnames, and see if the server reaches them. In cloud environments SSRF against the metadata endpoint can leak credentials and escalate into the account itself, which is why it climbed the OWASP list into its own spot.

Worth noting here: I see a lot of people report SSRF vulnerabilities just because they can make the server perform a HTTP request to a Collaborator instance. This is not a vulnerability by itself, in fact, it’s a necessary feature of many web applications. It only becomes a vulnerability if there is real security impact – like if you can call sensitive internal endpoints, pivot into an internal network, or grab cloud provider creds from the metadata endpoint.

7. Injection (SQL, NoSQL, command)

Injection is old but not dead. The API takes your input and passes it into a query or a shell without proper handling. In JSON APIs it hides in unexpected places, because a field the developer assumed was a string can carry a payload:

{"scope": "SELECT sleep(10)"}  // blind SQLi via timing
{"filter": {"$gt": ""}}        // NoSQL operator injection (MongoDB)
{"filename": "x; cat /etc/passwd"}  // command injection

NoSQL injection deserves a mention it didn’t get in 2021, because document databases are far more common now. Instead of SQL syntax you inject query operators like $ne, $gt or $regex to bypass authentication or dump data.

8. GraphQL-specific issues (new for 2026)

GraphQL wasn’t in the 2021 guide. It needs to be here. Instead of many REST endpoints, a GraphQL API exposes a single endpoint (usually /graphql) where the client asks for exactly the fields it wants. That flexibility creates its own bugs:

• Introspection left on hands attackers the full schema, as covered above.
• Nested query denial of service: GraphQL lets you request related objects in a loop (authors of books of authors of books…). A deeply nested query can force the server to do enormous work from one small request. Query depth and cost limits are the defense, and they’re frequently missing.
• Authorization per resolver: because one query can touch many objects, authorization has to be enforced on every field’s resolver, not at the endpoint. Miss one and you get a GraphQL-flavored BOLA. Test individual fields, not just the top-level query.
• Batching attacks: GraphQL can accept many operations in one request, which lets you bypass rate limiting on things like login or OTP checks by sending hundreds of attempts in a single HTTP call.

9. Unrestricted access to sensitive business flows (business logic)

Some abuse doesn’t break a technical control at all, it abuses a legitimate feature at a scale or in an order the business never intended: buying up limited stock with a script, farming referral bonuses, scraping an entire catalogue through a “recommendations” endpoint. These bugs need you to understand what the flow is for and then ask “what happens if I do this ten thousand times, or out of sequence?” Human judgement goes a long way here, it’s not something a scanner would find because it requires understanding the business.

10. AI and LLM-backed APIs (brand new)

This category simply didn’t exist in 2021. Now a large share of new APIs pass user input to a language model or call model-driven “tools” and “functions” behind the scenes. That opens a huge attack surface we haven’t had before:

• Prompt injection: if the endpoint feeds your input into a model’s prompt, you may be able to override its instructions, extract its system prompt, or make it misbehave. If the model can call functions (send email, query a database, hit another API), a successful injection can turn into real actions, essentially SSRF, injection and privilege escalation through natural language.
• Unbounded consumption: model calls are expensive. An endpoint with no limits on prompt size or request rate is a direct line to the target’s cloud bill, a costlier version of the rate-limiting problem above.
• Excessive agency: when the model is wired to tools, check what those tools can do and whether your input can steer them past their intended scope.

What’s the same, and what’s new

If you read the 2021 guide, here’s the short version of what carried over and what didn’t.

Still true

BOLA/IDOR is still king 👑. JWT misconfigurations still work occasionally. Undocumented endpoints, old API versions and staging hosts are still soft targets. Rate limiting is still missing more often than not. An intercept proxy and a request builder are still a core part of your toolkit. The core mindset, that the API will let you do things the UI never would, is still relevant.

New or much bigger in 2026

GraphQL is now mainstream and brings its own bug classes. OAuth/OIDC flows are everywhere and widely misconfigured. NoSQL injection matters more as document databases spread. Race conditions are far easier to test thanks to single-packet attacks. And an entirely new frontier of AI-backed endpoints has appeared, with prompt injection and unbounded consumption as the headline risks. OWASP also reorganized its API Top 10 in 2023, folding old categories together and promoting SSRF and inventory management, which tracks with what we see in real testing.

Another notable change is the actual workflow. AI is a huge part of a hacker’s workflow now, and frontier models are capable of performing a lot of the testing autonomously – with the right guidance.

Testing efficiently

When I approach an API, there’s a rough workflow that I follow.

Many APIs are big and complex, so prep is important. Start by mapping the whole surface first, note every object ID and token as you go, and test the same bug class across every endpoint before moving to the next class. A team that gets BOLA wrong on one endpoint usually gets it wrong on several. Automate the mechanical parts (discovery, fuzzing, JWT checks) and spend your human attention on authorization and business logic, which is where the scanners go quiet and the interesting bugs live.

The most important thing is to test methodically, making sure to systematically cover every endpoint and parameter.

Defending your APIs

If you’re on the other side of this, the fixes are less exotic than the attacks. It’s the same basic security hygiene that’s been around forever, but with a couple of modern twists.

As usual, enforce authorization on every request and every object, server-side, never trust an ID just because it’s hard to guess. Validate and allow-list input rather than blacklisting. Rate-limit per user, per IP and per endpoint, and treat expensive operations (SMS, email, model calls) as resources worth protecting. Keep an accurate inventory of every API, version and environment you expose, and retire the ones you don’t need to reduce exposure. Turn off GraphQL introspection in production and cap query depth and cost. And test continuously, because your attack surface changes every time you ship!

AI is also on your side now – you can use AI to test your systems continuously between pentests, verify trust boundaries between user roles, and provide real-time recommendations.

Wrapping up

The fundamentals of API hacking haven’t changed all that much since 2021: find the endpoints, understand what they’re meant to do, then do something they didn’t plan for. 

What has changed is the size and shape of the surface. GraphQL, OAuth sprawl and AI-backed endpoints have added new ground to cover, while the old reliable bugs, BOLA and broken auth chief among them, are still ripe for the picking! Learn the classes in this guide, test methodically, and you’ll find plenty.

Scan your entire attack surface for security flaws before they’re exploited in the wild. Book a demo or start a free trial with Detectify.