What is API security?

Why APIs are a prime attack target

APIs have properties that make them particularly attractive to attackers:

• Direct data access: APIs are designed to return structured data — often exactly the sensitive fields that attackers want (personal data, financial records, authentication tokens).
• Machine-readable and automatable: Unlike a website, an API can be probed at machine speed. An attacker can test millions of object IDs, credentials, or parameter combinations in minutes.
• Undocumented endpoints: Many APIs have "shadow" or legacy endpoints that developers forgot to secure or decommission. Attackers actively search for these.
• Third-party exposure: Mobile applications and partner integrations expose APIs to a much wider audience than internal web apps, increasing the attack surface dramatically.

The OWASP API Security Top 10

OWASP maintains a separate Top 10 specifically for API security risks. The most critical categories:

1. API1
   Broken Object Level Authorisation (BOLA) — The most common API flaw. An API endpoint that accepts a user ID parameter doesn't verify whether the caller is authorised to access that specific object. Changing /api/users/123/account to /api/users/124/account returns another user's data. Affects 78% of APIs.
2. API2
   Broken Authentication — Weak or missing authentication: API keys in URLs, no token expiry, accepting expired tokens, or credentials transmitted without HTTPS. Any authenticated API is only as secure as its authentication mechanism.
3. API3
   Broken Object Property Level Authorisation — APIs returning more data than the user is permitted to see, or accepting properties that the user shouldn't be allowed to set. A user updating their profile could elevate their own role if the API accepts a "role" field without checking permissions.
4. API4
   Unrestricted Resource Consumption — APIs without rate limiting or request size controls allow attackers to launch DoS attacks, scrape entire datasets, or brute-force credentials through the API at machine speed.
5. API5
   Broken Function Level Authorisation — Administrative API functions exposed without proper access controls. Attackers guess admin endpoints (/api/admin/users, /api/v2/admin/reset) and access them with a standard user token.

Building secure APIs

API security must be built in from design, not bolted on afterwards:

• Authenticate every request: Use industry-standard authentication (OAuth 2.0 + JWT). Never pass credentials or tokens in URLs. Set short token expiry times.
• Authorise at the object level: For every data-returning endpoint, verify not just that the user is authenticated but that they are permitted to access the specific resource being requested.
• Return only what is needed: Never return entire database objects. Filter API responses to include only the fields the caller is authorised to see.
• Implement rate limiting: Limit requests per API key, per endpoint, and per IP address. Return 429 Too Many Requests with a Retry-After header.
• Inventory your APIs: Maintain a complete registry of all API endpoints, versions, and who can access them. Decommission unused endpoints. The most exploited APIs are often ones the team forgot about.
• Test with automated scanners: Tools like OWASP ZAP, Burp Suite, and Postman can test APIs for the OWASP API Top 10 during development and in CI/CD pipelines.