API security is the discipline of protecting APIs from unauthorized access, abuse, and vulnerabilities, and it’s simultaneously one of the most important and most chronically underinvested areas of API operations. APIs are, by design, doorways into your systems and data — and a doorway is a security concern by definition. Every API exposes some capability or data to the outside world, and securing that exposure is foundational to operating responsibly. I’ve written about API security throughout my work, and the persistent theme is the gap between how important security is and how little organizations actually invest in it until something goes wrong. API security isn’t a feature you add at the end; it’s a property that has to be designed in, enforced continuously, and treated as a first-class concern across the entire lifecycle — and the failure to do so is one of the most common and most damaging patterns in the whole API economy.
The foundations of API security are knowable, and I tried to make them accessible early. I wrote “securing your API 101” in 2013 as a plain-English introduction, because the basics — authentication (who are you), authorization (what are you allowed to do), encryption in transit, rate limiting, input validation — are the foundation everything else builds on. The authentication and authorization layer, implemented through API keys, OAuth, and JWT, is where most API security lives: identifying consumers and controlling what they can access. I’ve written that rate limiting itself is a form of security, because controlling how much a consumer can do limits the damage of abuse. These foundations aren’t exotic; they’re well-understood practices. The problem is rarely that organizations don’t know what API security requires — it’s that they don’t prioritize implementing it until a breach forces them to.
The OWASP framing brought rigor to API security, and I championed it. I wrote in 2017 about the OWASP API security project and the work to define the specific ways APIs get attacked — broken authentication, broken object-level authorization, excessive data exposure, and the rest of what became the OWASP API Security Top 10. This was important because API security has its own distinct threat model, different from general web application security: the ways APIs get attacked are specific, and naming them precisely is the first step to defending against them. The API Evangelist API security industry guide I published in 2017 was an attempt to map the whole landscape of API security — the threats, the practices, the tools, the vendors. The unknown unknowns of API security, which I wrote about the same year, captured the harder truth that you can’t defend against threats you haven’t even conceived of, which is why API security requires continuous vigilance rather than a one-time hardening.
The awareness-and-observability dimension is where API security connects to the operational reality of knowing what’s happening. I wrote in 2019 about the role that awareness of your API traffic plays in API security — because you can’t secure what you can’t see. Knowing who’s calling your APIs, what they’re accessing, what patterns look normal and what looks anomalous, is foundational to detecting and responding to attacks. This is why API management, logging, and observability are security infrastructure: they’re how you maintain the awareness that security depends on. An API you’re not observing is an API you can’t secure, because the first sign of an attack is usually an anomaly in the traffic, and you can only catch the anomaly if you’re watching. Security and observability are deeply intertwined — the awareness that observability provides is the precondition for the security that protects you.
The political and economic reality of API security is where I’ve been most pointed, because the underinvestment is a structural problem, not just an oversight. I wrote in 2018 that investment in API security will continue to fall short while there is no breach accountability — and this is the crux. Organizations underinvest in security because the costs of a breach are often externalized: the consumers whose data is exposed bear the harm, while the organization that failed to secure the API faces limited consequences. Without real accountability — regulatory penalties, liability, genuine consequences — the rational economic calculation favors underinvestment, because security costs money up front while the costs of insecurity fall on others and only sometimes on you. I’ve written about the politics and fear of security, the way security gets weaponized for marketing, and the way “security investments will affect profitability” gets used to justify cutting corners. Put plainly, API security underinvestment is substantially a problem of misaligned incentives, and fixing it requires accountability that makes the cost of insecurity fall where it belongs.
The governance synthesis is where modern API security becomes a manageable, systematic practice rather than a reactive scramble. I wrote in 2025 that API governance rules provide a secure baseline to start from, and about governing API authentication — because security, like the rest of API quality, can be substantially governed through machine-readable rules that enforce security requirements automatically. Governance rules can check that every API declares appropriate security schemes, that sensitive data is handled correctly, that authentication is properly configured. This is the maturation of API security from a separate, reactive discipline into an integrated, continuous, governed property of how APIs are built. What it comes down to is that API security is foundational and non-negotiable — every API is a doorway, and securing it is a basic responsibility — but it’s chronically underinvested because the incentives are misaligned and security gets treated as an afterthought rather than a design property. The path forward is treating security as a first-class, continuous, governed concern: designing it in from the start, enforcing it through governance rules in the pipeline, maintaining the observability that detects threats, aligning incentives through accountability so the cost of insecurity falls where it should, and recognizing that an API’s security is not a feature to be added but a property to be designed, enforced, and continuously maintained. The organizations that treat security this way protect their consumers and themselves; the ones that wait for a breach to take it seriously are gambling with data and trust that aren’t theirs to gamble with. API security is where the responsibility of operating a doorway into your systems becomes concrete, and meeting that responsibility is one of the most important and most neglected obligations in the entire field.
References
- Securing Your API 101
- The Unknown Unknowns Of API Security
- The API Evangelist API Security Industry Guide
- The Open Web Application Security Project (OWASP) And API Security
- Explaining API Security To Organizational Leadership
- Investment In API Security Will Continue To Fall Short While There Is No Breach Accountability
- The Role Having Awareness Of Your API Traffic Plays In API Security
- API Governance Rules Provide A Secure Baseline To Start From
- Governing API Authentication
