Today I want to tell a slightly different story.

I wrote this story because when people think about API attacks, they often imagine exploits, malware, or some ultra-advanced hacking technique.

Two years ago, I decided to help a friend who had just started pentesting APIs. I will not mention which company’s APIs we were working on, but it had a buying system and a huge API infrastructure used by millions of people.

Back then, I was heavily focused on API security: testing products, experimenting with different tools, and supporting customers who were using them. That was the reason I decided to help my friend.

So here is my journey into learning how an attacker can abuse APIs.

FIND APIs

The first thing I did — and the first thing an attacker would do — was find the APIs.

At the beginning, I was simply discovering them through the browser’s Network tab. Later, I found a really cool tool called HTTP Toolkit. (No, this is not an advertisement. I’m not getting paid by them.)

HTTP Toolkit allowed me to inspect APIs much faster while navigating through the application, and it also introduced me to Frida — which is an amazing tool for inspecting a mobile app’s API requests and a lot more.

At that point, I genuinely thought I was finding every API I needed from both the website and the mobile app.

But guess what?

I absolutely was not.

There were hidden APIs being used internally by admins.

So how did I find them?

Do you remember those massive JavaScript files you see in the browser Network tab? The single-line, million-character-long, heavily obfuscated nightmare?

Yeah. Those.

It turned out they contained a lot more than frontend logic. They contained API endpoints, request structures, and sometimes even clues about how internal functionality worked.

If you take the time to deobfuscate, beautify, and actually read through the code, you can discover a surprising amount of APIs.

And here’s the important part:

Some admin APIs and admin JavaScript bundles should only be loaded after proper privilege validation. But not everybody is careful about that.

That is how we ended up finding multiple internal/admin APIs that were extremely useful.

HIDE FROM SECURITY

Our goal was never to damage the system. We wanted to understand how protections worked, bypass certain controls, and gain advantages in the testing process.

To do that, I started automating legitimate API requests we had collected.

I wrote everything in Python. Maybe not the perfect choice performance-wise, but it was fast enough for testing ideas and prototyping.

The first thing I built was a bot that replicated API calls exactly the way a real user would. It waited realistic amounts of time between requests, behaved naturally, and avoided obvious automation patterns.

Then I added threading.

Then proxies.

A lot of proxies.

At first, it worked pretty well. But eventually security systems started detecting the automation. Proxies were getting banned constantly.

The detections were happening because of:

That last part was especially interesting.

I was using Python’s requests library, which relies on OpenSSL for TLS negotiation. Browsers do not behave exactly the same way during TLS handshakes, and modern security systems absolutely notice those differences.

So I started fixing everything:

Eventually, the traffic became close enough to legitimate browser behavior that most security layers stopped flagging it immediately.

But there was still one final boss:

Captcha.

For invisible captchas, I used headless browser automation with Playwright. Some captchas only verify whether you are operating through a real browser environment, even if the user never sees a challenge on screen.

So I would launch browser instances on blank pages, generate valid captcha tokens, and reuse those tokens while performing actual actions elsewhere.

For visible captchas — and sometimes invisible ones too — I used third-party solving services that charged a few cents per solve.

ABUSE

In this specific case, I was mostly interested in business logic flaws and misconfigurations.

While I was building automation and bypassing protections, my friend focused on testing weird edge cases:

I know the examples sound generic, but I obviously cannot share real production examples.

One of the funniest findings was related to endpoint capitalization.

For the backend:

…were treated as different endpoints by the rate limiter.

Which meant throttling limits could be bypassed simply by changing capitalization.

So suddenly we were operating multiple times faster without waiting for cooldowns, rotating requests across hundreds of proxies while varying endpoint casing.

Honestly, it was both hilarious and terrifying.

FINALE

Eventually, we merged everything together into a single system:

The final result was a tool capable of sending massive amounts of requests while blending into normal traffic patterns and abusing logic flaws along the way.

As I said in the beginning: “I wrote this story because when people think about API attacks, they often imagine exploits, malware, or some ultra-advanced hacking technique.”

But in reality, a lot of API abuse comes from understanding:

Sometimes the scariest attacks are built almost entirely from legitimate requests.

The Scariest API Attacks Are Boring: Anatomy of API Abuse was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.