API Security: How Attackers Exploit Hidden Endpoints, Forge Tokens, and How Kong Gateway Stops Them

Your API documentation is a lie.

Not on purpose. But pull up your Swagger file right now and compare it to what’s actually running in production. There’s a gap. There’s always a gap. Maybe it’s an admin route from two quarters ago that nobody tore down. Maybe a developer pushed a debug endpoint to staging, and it leaked into prod. Maybe there’s a beta feature behind a predictable URL with no auth at all.

These things pile up. Every team says they’ll clean it up next sprint. They won’t. Not all of it. Not across every service.

And here’s the thing: attackers aren’t reading your API docs. They’re fuzzing your infrastructure at scale and finding routes your own security team has no idea are live.

Practical DevSecOps recently hosted a hands-on workshop where Principal Security Consultant Marudhamaran Gunasekaran showed, live in a terminal, how security engineers break into REST APIs. Then he flipped to the defense side and demonstrated how Kong API Gateway shuts down those exact attack patterns.

This article walks through the full methodology. Want to see it happening in real time? Watch the complete API Security Workshop here.

Also read Level up your skills with API Security Training 

Most Applications Trust Their JWTs Too Much

Whenever API security comes up, someone asks “are your tokens encrypted?” Wrong question. Completely wrong question.

Quick primer if you need it: a JWT has three parts separated by periods. Header, payload, signature. The payload is where the interesting stuff lives: user IDs, roles, permissions, expiration times. And it’s Base64URL-encoded. That’s encoding. Not encryption. Anybody who grabs the token can read the payload. Takes seconds.

But honestly? That part isn’t what gets companies breached.

What gets them breached is how the backend handles the token once it shows up. Most apps do something like this: check if the JWT exists, verify the signature, read the role claim, grant access. Done. The server treats whatever the token says as gospel. “This user is an admin.” Okay, you’re an admin. No second opinion. No checking against the actual database.

So if an attacker finds a weak signing algorithm, gets their hands on a leaked key, or discovers a flaw in how the server validates signatures? They don’t need to break into anything. They just edit the payload, re-sign the token (or skip the signature entirely if the server accepts alg: none), and the server rolls out the red carpet.

Marin showed in the workshop how pentesters automate all of this. You send a login request, grab the token from the response with a JSON parser, stuff it into a shell variable. Now every request you make carries that token automatically. What used to be ten minutes of clicking around in browser dev tools turns into a script that hits hundreds of endpoints before your coffee gets cold. Databases, user lists, admin panels… if the JWT is the only thing standing guard, none of it is safe.

The fix? Nothing groundbreaking. Validate claims on the server side for every single request. Keep token lifetimes short. Rotate your signing keys. Most teams know all this already. The problem is actually doing it, consistently, across every service in production. That gap between “we know we should” and “we actually did” is exactly where breaches happen.

API Fuzzing: Finding the Endpoints Your Team Forgot About

So now the attacker has a valid token and can authenticate. Bad enough. But the real damage? That starts when they find endpoints your security team doesn’t even know are there.

This next part should genuinely make you uncomfortable about your own infrastructure.

Also read about API Security Trends 

Hidden Endpoints Are Your Biggest Blind Spot

New code ships every sprint. Old code? That sticks around. Features get abandoned but never removed. Internal routes get accidentally exposed through a routing change nobody reviewed carefully enough. “Temporary” prototype endpoints are still running eighteen months later because nobody owns the cleanup.

Here’s the uncomfortable truth: your API docs don’t reflect what’s actually live. They never do. Not fully. And you can’t put security controls on something you don’t know is there.

Why REST APIs Are So Easy to Fuzz

REST naming conventions are predictable, and that predictability is the problem. Routes almost always follow an object-action pattern. The object is your resource (users, products, coupons). The action is what you’re doing with it (register, save, delete, export). You don’t need insider access to guess these. You just need a decent wordlist.

In the workshop, Marin used ffuf for this. It’s a fuzzing tool written in Go that’s absurdly fast. You feed it two wordlists at once: objects and actions. It combines every entry from both lists, jams them into the URL, and fires off requests for every combination. We’re talking tens of thousands of guesses hitting the server in minutes.

The 405 Signal That Gives Everything Away

Pay attention here. This is the single most useful technique in this entire article, and it’s one most security teams completely miss.

When you fuzz an API, a properly configured server sends back 404 for routes that don’t exist. Simple enough. But a lot of APIs throw a generic 403 Forbidden at any unauthorized request, regardless of whether the endpoint is actually real. So your fuzzing results are just… thousands of 403s. All identical. You can’t tell what’s real and what doesn’t exist. Total noise.

Most people look at that wall of 403s and assume everything’s locked down. Nope.

What you’re actually looking for is 405 Method Not Allowed.

A 405 is the server telling you: “this endpoint exists, it’s running, but you sent the wrong HTTP method.” Your fuzzer threw a GET at /users/register and the server’s sitting there waiting for a POST.

Also read about API Security Books 

What a 405 tells an attacker:

• The endpoint exists
• It’s actively running on the server
• They need to switch HTTP methods and supply a request body to interact with it

Filter your fuzzing output. Strip out every 403. Look at what’s left. The 405s point you straight to hidden admin routes, registration endpoints nobody documented, internal management tools that were never meant to face the public internet.

That’s how a “fully secured” API turns out to have an entire shadow attack surface that nobody was watching. Seriously, if you take one thing from this post, go fuzz your own production API tonight and filter for 405s. You might not love what turns up.

Why Writing Security Logic Into Every Microservice Is a Losing Strategy

Okay, defense time. And let’s start with something most engineering orgs won’t admit out loud: the way they’re doing API security right now doesn’t work.

The default approach is to bake auth checks, rate limiting, and input validation into every microservice. Sounds reasonable until you see what actually happens. Team A adds solid rate limiting to the user service. Team B rolls their own token validation for payments, does it slightly differently. Team C owns that legacy service from 2021 that nobody wants to touch. They did nothing.

Now you’ve got a patchwork. One weak service is all it takes. An attacker finds it, gets in, and suddenly they’re behind your perimeter talking to everything else. You can’t audit this setup consistently. You can’t push updates uniformly. A new CVE drops and you’re scrambling to patch a dozen services maintained by different teams on different timelines.

If your security model requires every team, across every service, to get it right on their own, every single time? That model is already broken. You just haven’t found out yet.

Also read about the API Security Vulnerabilities Guide 

How Kong API Gateway Centralizes API Defense

Kong is an open-source API gateway that sits between all external traffic and your backend services. Every request hits the gateway first. Nothing reaches the backend without passing through Kong’s security controls.

It’s not a silver bullet. No gateway is. But it solves the centralization problem that makes per-service security unmanageable.

Setup: Services, Routes, and the Step Most Teams Skip

The architecture uses two concepts. A service represents the backend application being protected. A route defines the public-facing URL path external clients use to reach that service.

But configuring services and routes is only half the job. The step most teams skip, and the one that matters most, is killing direct access to backend servers entirely. If an attacker can bypass the gateway by hitting a server’s IP address, every policy you’ve configured is meaningless. All external traffic must be forced through Kong. No exceptions.

The request flow should look like this:

External Client → Kong Gateway (auth, rate limits, validation) → Backend Service

Not this:

External Client → Backend Service (no controls)

If both paths are open, you don’t have API security. You have an optional suggestion.

Rate Limiting: Killing Automated Attacks

With the gateway handling all inbound traffic, you deploy security plugins globally without touching application code. For defending against fuzzing, brute-force, and scraping attacks, rate limiting is the most immediately impactful.

Instead of each team implementing their own rate-limiting logic (inconsistently, with different thresholds), you enable Kong’s rate-limiting plugin on the route. One configuration. It tracks request volume by session ID, JWT claims, IP address, or custom headers.

In the workshop demo, Marin configured five requests per minute, tracked by X-API-Key header. Legitimate users never notice. But the moment an attacker launches ffuf or a scraping script, the gateway tracks every request.

Request six gets dropped. HTTP 429 Too Many Requests. The backend never sees it. The database is never touched.

The fuzzing attack that would have mapped dozens of hidden endpoints? Dead after five requests. The brute-force script targeting the login endpoint? Blocked before it tests a sixth password.

Where Rate Limiting Falls Short

Here’s what rate limiting won’t catch: a patient attacker.

If someone manually probes your API at four requests per minute, staying just under the threshold, rate limiting won’t flag it. If an attacker distributes requests across multiple IP addresses or API keys, simple per-key limits won’t stop them.

Rate limiting neutralizes automated, high-volume attacks. That’s significant, because the vast majority of API attacks are automated. But it’s one layer, not the whole defense.

A complete gateway security posture also includes centralized token validation (rejecting malformed or expired JWTs before they reach the backend), request schema enforcement (blocking unexpected parameters and malformed payloads), traffic observability (logging every failed auth attempt and anomalous pattern for incident response), and IP-based access controls for geo-restriction or blocklisting known malicious sources.

Each is a plugin configuration, not a code change. Each applies globally. Each is auditable from a single control plane. That’s the difference between API security that works on paper and API security that holds up when someone actually tries to break in.

Also read about how to ensure API Security while maintaining Developers productivity 

Your Move

Here’s what this comes down to.

Your API has endpoints you haven’t documented. Your JWTs are probably trusted more than they should be. And if your security controls are scattered across individual services instead of enforced at a gateway, you have gaps you can’t see.

None of this is theoretical. These are the exact techniques attackers use against production APIs every day. The workshop walked through all three phases, token exploitation, endpoint fuzzing, and Kong Gateway configuration, with live terminal demonstrations.

Watch the full API Security Workshop on the Practical DevSecOps YouTube channel and run these same techniques against your own infrastructure. Better you find the holes than someone else.

Build real API security skills through hands-on labs, not multiple-choice theory. The Certified API Security Professional (CASP) program from Practical DevSecOps tests you in practical, real-world environments, because that’s how security actually works.