Web API security is the practice of protecting your application's APIs from abuse by controlling who can call each endpoint, what actions they're allowed to perform, and what data each response can return. APIs are now the primary attack surface for most applications, because they expose business logic and data directly, often with less UI-layer friction than a traditional web page. Getting web API security right is less about a single silver-bullet control and more about consistently enforcing identity, authorization, and input handling on every endpoint. This guide covers the risks that actually cause breaches and the defenses that address them.
Why APIs are the attack surface now
A decade ago attackers probed HTML forms. Today they hit JSON endpoints, because that's where the logic lives. Single-page apps, mobile clients, and service-to-service calls all run over APIs, and those APIs frequently return more data than the client displays, trust parameters they shouldn't, or check authentication without checking authorization.
The OWASP API Security Top 10 codifies the recurring failures, and the top entries are consistent: broken authorization (both object-level and function-level) and broken authentication dominate real incidents. Notably, most of the worst API breaches aren't exotic — they're missing or wrong access-control checks on endpoints that otherwise work fine.
Authentication: proving who is calling
Authentication establishes identity. The common patterns:
- API keys — simple, but they only identify an application, not a user, and are easy to leak. Fine for low-risk service identification, weak as a sole auth mechanism.
- OAuth 2.0 / OpenID Connect — the standard for delegated, token-based access. Well-suited to user-facing APIs and third-party integrations.
- JWTs (JSON Web Tokens) — a common token format. Powerful but easy to misuse: validate the signature and algorithm (reject
alg: none), check expiry, and never trust claims without verifying the token.
The recurring authentication mistakes are practical, not theoretical: tokens that never expire, secrets checked into source control, and JWTs whose signatures aren't actually verified server-side. Get the basics enforced consistently before reaching for anything fancier.
Authorization: the failure that causes most breaches
Authentication tells you who is calling. Authorization decides what they're allowed to do — and this is where APIs most often fail.
The classic bug is broken object-level authorization (BOLA), sometimes called IDOR. An endpoint like GET /api/orders/1043 authenticates the caller but doesn't check that order 1043 belongs to them. Change the ID to 1044 and you read someone else's order. It's trivial to exploit and devastating at scale.
The fix is discipline, not cleverness: every request that references a resource must verify the authenticated user is authorized for that specific resource, server-side, on every endpoint.
# Conceptual check on every resource access
requested = load_order(order_id)
if requested.owner_id != current_user.id:
return 403 # never 200, never "just return it"
The related broken function-level authorization is exposing an admin endpoint that any authenticated user can call because the role check was forgotten. Both come down to enforcing access control at the point of every action, never assuming the client will only call what the UI shows it.
Input validation and data exposure
Two more high-frequency issues:
Injection and input handling. APIs must validate and sanitize all input — treat every parameter, header, and body field as untrusted. Use parameterized queries to prevent SQL injection, validate types and ranges against a schema, and reject rather than coerce malformed input. Defining a strict request schema (OpenAPI, JSON Schema) and validating against it turns a whole class of bugs into automatic rejections.
Excessive data exposure. A frequent API-specific flaw is returning full internal objects and relying on the client to display only some fields. Serializing a user object that includes passwordHash, internal flags, or other users' data leaks it to anyone reading the raw response. Return only the fields a response needs — shape the output explicitly rather than dumping the database row.
Rate limiting, transport, and operational controls
Beyond auth and input, a few controls round out a defensible API:
- Rate limiting and throttling. Without limits, APIs are open to credential stuffing, scraping, and denial of service. Limit by client, endpoint, and sometimes by resource cost.
- TLS everywhere. All API traffic over HTTPS, no exceptions. Tokens and data in transit must be encrypted.
- Security headers and CORS. Configure CORS narrowly — a wildcard
Access-Control-Allow-Originon an authenticated API is a common misstep. - Logging and monitoring. Log authentication and authorization failures so abuse is visible. An API being probed for BOLA generates a distinctive pattern of 403s and sequential IDs.
- Inventory your endpoints. You can't secure what you don't know exists. "Shadow" and deprecated-but-live endpoints are a frequent entry point.
Building API security into the pipeline
API security isn't a one-time audit; it's enforced continuously as code changes. Static analysis catches some issues in code, but many API flaws — a missing authorization check, an endpoint returning too much data — only reveal themselves when the API is actually running and probed. A DAST tool exercises a live API and surfaces broken authorization and injection issues that static review misses, which is why runtime testing is a core part of API security.
Pair that with dependency scanning, since a vulnerable framework or parser handling your API traffic is its own risk — an SCA workflow covers that half, and a tool such as Safeguard can correlate a runtime API finding with the vulnerable library behind it. For structured learning on the OWASP API risks, our security academy walks through each category with examples.
FAQ
What is the biggest web API security risk?
Broken authorization — specifically broken object-level authorization (BOLA/IDOR), where an endpoint authenticates the caller but fails to check they're allowed to access the specific resource requested. It tops the OWASP API Security Top 10 and is behind many real-world API breaches because it's easy to exploit.
What's the difference between API authentication and authorization?
Authentication proves who is making the request (via API keys, OAuth tokens, or JWTs). Authorization decides what that identity is allowed to do and which resources it can access. APIs commonly get authentication right but fail authorization by not checking resource ownership on every request.
How do I secure a JWT-based API?
Verify the token's signature server-side on every request, reject the none algorithm, enforce expiry, and validate claims rather than trusting them. Keep signing secrets out of source control, use short-lived tokens with refresh, and never rely on the client to enforce token validity.
Can automated tools test web API security?
Yes. DAST tools exercise a running API to find broken authorization, injection, and data-exposure issues that static analysis can't see, while SCA tools flag vulnerabilities in the frameworks and libraries handling your API traffic. Both belong in the CI pipeline alongside schema validation.