Every few years, a gap opens up in the technology industry. A new discipline emerges, demand for it explodes, and for a brief window — before the market catches up — the people who saw it early build careers that take decades to replicate.
Cloud architecture was one. DevOps was another.
API security is next. And most people haven’t noticed yet.
I want to tell you why — and what to do about it.
The world runs on APIs now
Not metaphorically. Literally.
Every time you tap your phone to pay for something, an API moves money between banks. Every time a logistics system updates a delivery status, an API fires between a warehouse management system and a customer portal. Every time a field technician logs a work order on a mobile app, an API carries that data to a server somewhere.
APIs are the connective tissue of modern software. They’re how systems talk to each other, how mobile apps talk to back-end, how businesses talk to other businesses.
And they are, broadly speaking, insecure.
Not because developers are careless. Not because companies don’t care. But because API security is genuinely hard to get right, the tooling to catch mistakes is immature, and the industry hasn’t yet produced enough people who truly understand the problem at depth.
That gap — between how critical APIs are and how poorly most of them are secured — is the opportunity.
The numbers are uncomfortable
In 2023, Gartner predicted that APIs would become the most frequent attack vector for enterprise breaches. That prediction has aged well.
The breaches you read about — the ones that make headlines, trigger regulatory investigations, and end careers — are increasingly API breaches. Not network breaches. Not endpoint breaches. API breaches.
- Coinbase — Coinbase experienced one of the most significant API vulnerabilities in recent history, where unauthorized trading was possible through a vulnerable API endpoint. This case represents a textbook example of BOLA, the #1 API security threat
- Instagram — Instagram suffered from API vulnerabilities that allowed attackers to literally take over any user’s account.
- T-Mobile — 37 million customer records exposed through an API that had no rate limiting and no authentication requirement on a specific endpoint
- Optus — an unauthenticated API exposed the personal data of 9.8 million Australians
These weren’t sophisticated nation-state attacks. They weren’t zero-days. They were basic API security failures that any engineer who knew what to look for could have caught in a code review.
That’s the part that should make you stop and think.
Why so few people actually specialize in this
Here’s the uncomfortable truth about the security industry: most of it is still organized around perimeter defense.
Firewalls. Endpoint detection. Network monitoring. These disciplines are mature, well-understood, and heavily staffed. The tooling is sophisticated. The career paths are well-defined.
API security doesn’t fit neatly into that world.
It sits in the middle. And things that sit in the middle tend to get owned by nobody.
The result is a discipline that is critically important, genuinely difficult, and severely undeserved by the talent market. Companies know they have a problem. They don’t know who to hire to fix it. They often can’t even articulate what the role should look like.
Write on Medium
That’s the gap.
What makes this moment different
A few things are converging right now that make API security uniquely valuable to learn:
The attack surface has exploded. The shift to microservices, mobile-first architectures, and third-party integrations has multiplied the number of APIs in the average enterprise by an order of magnitude. More APIs means more surface area. More surface area means more risk — and more demand for people who understand it.
Regulation is catching up. GDPR, PCI-DSS v4.0, and emerging frameworks like DORA in Europe are starting to hold organisations accountable for API-level data exposure. Compliance requirements create budget. Budget creates hiring. Hiring rewards specialists.
The tooling is maturing. Spectral for API linting, Salt Security and Noname for API posture management, OWASP’s own API Security Top 10 as a structured framework — the industry is building the vocabulary and the toolset to talk about this problem systematically. Early specialists in a maturing discipline are disproportionately rewarded.
AI is making it worse before it’s better. AI-assisted development is accelerating API creation. Developers are shipping APIs faster than ever — and the security review process hasn’t kept pace. The gap between “APIs created” and “APIs properly secured” is widening. Every API a developer ships with AI assistance is a potential API a security engineer needs to review.
Agentic AI is about to multiply your API attack surface by an order of magnitude.
Until recently, APIs were called by humans — or by software acting on human instruction in real time. That is changing fast. AI agents — autonomous systems that plan, execute, and chain together API calls without human intervention — are becoming a mainstream architectural pattern.
OpenClaw, the open-source AI agent framework that went from zero to 145,000 GitHub stars in weeks, is a signal of where things are heading. These agents autonomously manage emails, book services, trigger workflows, and call APIs — at machine speed, at scale, around the clock. Meta’s acquisition of Moltbook, an AI-agent-only social platform, and their $2 billion acquisition of Manus, are billion-dollar bets on this future arriving faster than most people expect.
For API security, this changes everything. Rate limits designed for human usage patterns break instantly when agents call your API in coordinated loops. Business logic that assumed a human was making the decision is now being executed autonomously by a model that doesn’t understand context. Authentication flows designed for sessions get hammered by stateless agent calls. The OWASP API Security Top 10 was written for a world where humans called APIs. In the agentic world, the same vulnerabilities exist — but the blast radius of each one is exponentially larger.
If API security is undervalued today, it will be critically urgent tomorrow.
What this series covers
This is the first article in a eleven-part series on the OWASP API Security Top 10. Each article is designed to stand alone — but they’re better together. Follow to get notified when the next one drops.
Over the next ten articles, I’m going to walk through every item on the OWASP API Security Top 10 — the industry-standard framework for understanding and addressing the most critical API vulnerabilities.
For each one, we’ll cover:
- What it is and why it matters — in plain English, not textbook definitions
- What it looks like in real code — because abstract concepts don’t ship, code does
- How to find it — both as a developer reviewing your own work and as a tester looking for weaknesses
- How to fix it — practical, implementable, architect-level guidance
- The one thing to remember — because you’ll encounter this in the wild and you need it to stick
This isn’t a certification study guide. It’s not a compliance checklist. It’s a practitioner’s field manual — the kind of resource I wish I’d had when I started going deep on this.
A word on timing
I said the window is closing. I mean it.
Right now, API security expertise is rare enough to be genuinely differentiating. The number of engineers who can walk into a room, look at an API design, and say “here are five ways an attacker would approach this and here’s how I’d fix each one” — that number is small.
In five years, it won’t be. The curriculum will have caught up. The certifications will be commoditised. The tooling will automate more of the detection. The edge will narrow.
The time to build deep expertise in a discipline is before the market fully prices it in. That time, for API security, is now.
Who is Cyberbali ?
I’m a security architect focused on API security architecture. I work on designing and hardening API systems, run security workshops for engineering teams, and publish practical security tooling on GitHub. Visit cyberbali.in for more info.
This series is my attempt to write the resource I wish had existed when I started going deep on this problem.
Top comments (0)