Every product team ships an API before it ships a UI now. Mobile apps, partner integrations, internal microservices, and the AI agents plugging into your systems all talk through the same set of endpoints. That concentration of traffic makes the API layer the single most attractive target in your stack, and attackers know it. The Verizon 2025 Data Breach Investigations Report lists web application and API attacks among the top vectors behind confirmed breaches, and the traffic keeps shifting away from browser sessions toward machine-to-machine calls that most security teams still monitor less closely than they monitor user logins.
OWASP ranks broken object level authorization as API1 on its 2023 API Security Top 10, and it still causes more real-world incidents than any other API flaw. The pattern is simple and teams keep shipping it anyway: an endpoint like /api/orders/12345
authenticates the caller correctly but never checks whether that caller actually owns order 12345. Swap the ID and you read or modify someone else's data.
Fix this at the object level, not the endpoint level. Every handler that touches a resource by ID needs an explicit ownership or permission check before it returns data, not just a valid session token at the door. Centralize that check in a shared authorization library or policy engine so individual developers cannot forget it under deadline pressure. Run automated authorization fuzzing against your API test suite the same way you run functional tests. Postman's State of the API Report has flagged authorization testing as one of the most commonly skipped steps in API development workflows for several years running, and BOLA keeps showing up in bug bounty reports because teams still treat authentication and authorization as the same problem.
APIs that wrap or front a language model carry risks that a standard REST API doesn't. The OWASP Top 10 for LLM Applications names prompt injection, excessive agency, and insecure output handling as leading risks, and all three surface directly through your API layer, not just through a chat widget.
Treat every field a user or an upstream system can influence as untrusted input to the model, and treat every model output as untrusted input to your downstream systems. Do not let a model response trigger a database write, a file operation, or a call to another internal API without validation in between. If you expose function calling or tool use through your API, scope each tool narrowly and require explicit allowlists rather than granting a model broad access to your internal endpoints. Rate limit by token cost and by the expense of downstream actions a call can trigger, not just by request count, since a single prompt can fan out into dozens of internal calls. When AI agents call your APIs autonomously, issue each agent its own short-lived, narrowly scoped credential instead of a shared service account. A shared credential turns one compromised agent into full access for every agent using it.
Perimeter-based security assumes a trusted internal network, and that assumption breaks down once your services span multiple clouds, third-party integrations, and AI agents making calls on a schedule you don't fully control. Zero trust treats every request as untrusted until it proves otherwise, and the API gateway is where you enforce that policy consistently instead of relying on each service to get it right independently.
Put mutual TLS between services so both sides authenticate the connection, not just the caller authenticating to the server. Issue short-lived OAuth 2.0 tokens with narrow scopes instead of long-lived API keys that grant broad access for months at a time. Define scopes around specific actions (orders:read
, orders:write
) rather than broad resource-level access, so a compromised token limits the blast radius. Enforce rate limiting and quota policy at the gateway per client identity, not per IP address, since IP-based limits fall apart against distributed traffic and legitimate multi-tenant clients sharing infrastructure. Gartner has projected continued growth in spending on API security tooling and API gateways as organizations recognize that API traffic now outpaces traditional web traffic across most enterprise environments, and gateway-level policy enforcement is the practical way to apply zero trust without rewriting every service.
Hardcoded API keys and database credentials in source repositories remain one of the most common and most preventable causes of API breaches. GitHub's secret scanning program has flagged millions of exposed credentials across public repositories, and a meaningful share of those belong to production API keys committed by developers who meant to remove them before pushing.
Store secrets in a dedicated vault (HashiCorp Vault, AWS Secrets Manager, or your cloud provider's equivalent) and pull them into your application at runtime rather than baking them into configuration files or environment variables checked into version control. Rotate API keys and signing secrets on a fixed schedule, and rotate them immediately whenever a team member with access leaves or an incident suggests possible exposure. Prefer short-lived signed tokens over long-lived static keys wherever your architecture allows it, since a leaked token that expires in minutes does far less damage than a key that stays valid indefinitely. Add automated secret scanning to your CI pipeline so a committed credential blocks the merge instead of waiting for someone to notice in production.
None of these threats are new in concept. What changed is the surface area. Every internal microservice, every partner integration, and every AI agent your product now depends on adds another set of endpoints an attacker can probe, and the tooling attackers use to find broken authorization and leaked credentials has gotten faster than most teams' patch cycles. Treat API security as a design constraint from the first endpoint you write, not a checklist you run before launch, and build the habit of testing authorization and secrets hygiene the same way you test functionality.
Teams that want a structured way to build these habits across a whole engineering org, rather than relying on individual developers to pick it up ad hoc, should look at dedicated IT security training.