API security means making sure every endpoint authenticates the caller, authorizes every object and field it returns or changes, and limits how much and how it can be used. The OWASP API Security Top 10 (2023 edition) is the reference for where to start: three of its ten risks are authorization failures, and those are exactly the flaws automated scanners miss.
Why APIs are the main attack surface
An API is the door through which your mobile app, web app, partners and increasingly AI agents reach your data and business logic. In a modern product the UI only displays; security decisions happen in the API. If the API trusts what the client says ("I am user 15", "I am an admin"), anyone with a free intercepting proxy can change those values. That is why, in a mobile app penetration test, most critical findings show up in the backend, not on the phone.
The OWASP API Security Top 10 2023 at a glance
| ID | Risk | In one sentence |
|---|---|---|
| API1 | Broken Object Level Authorization (BOLA) | I can read or change another user's object by changing an ID. |
| API2 | Broken Authentication | I can impersonate someone through flawed login, token or reset logic. |
| API3 | Broken Object Property Level Authorization | The API exposes or lets me modify fields it should not. |
| API4 | Unrestricted Resource Consumption | No limits, so attackers exhaust resources or run up your SMS, email or AI bill. |
| API5 | Broken Function Level Authorization | A regular user can call admin functions. |
| API6 | Unrestricted Access to Sensitive Business Flows | Bots abuse a legitimate flow: purchases, sign-ups, coupons. |
| API7 | Server Side Request Forgery (SSRF) | The API fetches a URL I supply and reaches internal resources. |
| API8 | Security Misconfiguration | Open CORS, verbose errors, weak headers or TLS. |
| API9 | Improper Inventory Management | Old versions, debug endpoints or forgotten APIs remain exposed. |
| API10 | Unsafe Consumption of APIs | You blindly trust what a third-party API returns. |
Authorization risks: API1, API3 and API5
API1: BOLA, the most common
Example: your telehealth app calls GET /api/v1/appointments/1043. An attacker changes it to 1042 and sees another patient's appointment and notes. Under HIPAA that is likely a reportable breach. Fix: scope every query to the owner on the server (WHERE id = ? AND patient_id = session_user), never to a client-supplied ID; use non-sequential identifiers as defense in depth, not as the fix.
API3: object property level authorization
Example: GET /api/users/me returns the full record, including a password hash or an is_admin flag; or PATCH /api/users/me accepts {"role": "admin"} (mass assignment). Fix: explicit response schemas per role and allow-lists of writable fields on every update.
API5: function level authorization
Example: the admin console calls DELETE /api/admin/users/88 and the backend only checks that a session exists, not that it belongs to an admin. Fix: deny by default, declare the required role on every route, and add automated tests that call admin routes with a regular user.
Authentication, consumption and business flows: API2, API4 and API6
API2: broken authentication
Example: the password reset endpoint accepts unlimited guesses of a 4-digit code, or the API accepts JWTs signed with alg: none. Fix: use a proven identity provider, validate signature, issuer, audience and expiry on every token, throttle attempts and require MFA for sensitive accounts.
API4: unrestricted resource consumption
Example: POST /api/otp sends one SMS per call with no limit, so a bot can burn hundreds of dollars overnight. The same applies to endpoints that call an LLM per request. Fix: rate limits per user, IP and device, capped pagination, payload size limits and spend alerts with your providers.
API6: sensitive business flows
Example: a bot creates thousands of accounts to redeem a sign-up credit, or buys out a limited drop. There is no technical bug: the API does what it should, at a scale that hurts the business. Fix: identify critical flows and add proportional friction: per-customer limits, device checks, automation detection and anomaly review.
Infrastructure, inventory and integrations: API7 to API10
API7: SSRF
Example: an "import image from URL" feature accepts http://169.254.169.254/ and returns credentials from the cloud metadata service. Fix: allow-list destinations, block internal ranges, never return raw responses and enforce IMDSv2 on AWS.
API8: security misconfiguration
Example: CORS that reflects any origin with credentials, stack traces with internal paths, or a public Swagger UI in production. Fix: hardened, version-controlled configuration, generic client errors and checks on every deploy.
API9: improper inventory management
Example: you shipped /v2 with new controls, but /v1 is still live without them, or a public staging-api holds real customer data. These are shadow APIs (never documented) and zombie APIs (should have been retired). Fix: a living inventory of hosts, versions and endpoints generated from your OpenAPI specs and gateway, with a retirement date for every version.
API10: unsafe consumption of APIs
Example: your backend stores an address returned by a shipping provider without validation, or follows redirects from a partner API. If that third party is compromised, the attack comes in through you. Fix: validate and sanitize every external response as if it were user input, and enforce TLS, timeouts and size limits. If your API feeds an AI agent, this risk compounds with the OWASP Top 10 for LLMs.
Defensive patterns: gateway, authorization and rate limiting
- API gateway as the single entry point: TLS, token validation, rate limiting, size limits and centralized logging. A gateway does not replace object-level authorization, which belongs in the service that owns the data.
- Centralized authorization: a policy layer or library (role- and attribute-based) used by every route instead of ad hoc
ifchecks in each controller. - Strict schemas: validate requests and responses against the OpenAPI spec and reject undeclared fields.
- Short-lived tokens with refresh token rotation and revocation.
- Pipeline security: automated authorization tests and spec scanning on every merge, as covered in DevSecOps for CI/CD.
If your backend runs on Node.js, Firebase or AWS, see also our guide to mobile app backends.
How to test your API security
- Inventory: collect the OpenAPI spec, real app traffic and published hosts, and diff them to find undocumented endpoints.
- Authorization matrix: for every endpoint, which role can do what to which object. It drives API1, API3 and API5 testing.
- Two users of the same role and of different roles, swapping IDs and tokens.
- Limit testing: request bursts, extreme pagination and oversized payloads.
- Configuration review: CORS, headers, error messages and exposed versions.
Automated tools help with API8 and part of API9; authorization and business-logic risks need a manual, grey box penetration test. Enterprise customers and SOC 2 auditors increasingly expect API coverage in that report, and it is how our cybersecurity services approach API assessments.
Logging and monitoring
Log the user, endpoint, object accessed, outcome and source on every request, without storing passwords, tokens or full sensitive values. Alert on bursts of 403 and 404 responses from one user (a classic sign of ID enumeration) and on unusual consumption. Those logs are also what you need to scope a breach under state notification laws or HIPAA.
Frequently asked questions
What is the OWASP API Security Top 10?
It is a list of the ten most critical API security risks, published by the OWASP Foundation. The current edition is 2023 and includes broken object level authorization (BOLA), broken authentication, unrestricted resource consumption, SSRF, improper inventory management and unsafe consumption of third-party APIs, among others. It is free and widely used as a baseline for designing and testing APIs.
What is BOLA in API security?
BOLA (Broken Object Level Authorization) happens when an API returns or changes an object based only on its identifier, without checking that it belongs to the requesting user. For example, changing the order number in the URL reveals another customer's order. The fix is to verify object ownership on the server for every request, not to rely on hard-to-guess IDs.
Is an API gateway enough to secure my API?
No. An API gateway centralizes useful controls such as TLS, token validation, rate limiting and logging, but it cannot know whether record 1042 belongs to the user requesting it. Object- and field-level authorization must be enforced in the service that owns the data, and tested with users holding different roles.
What are shadow and zombie APIs?
Shadow APIs are production endpoints that are not documented or inventoried, often created for a test or a one-off integration. Zombie APIs are old versions that should have been retired but remain live, usually without the newer security controls. Both fall under API9, Improper Inventory Management, and are controlled with a living API inventory.
How often should we test API security?
Run automated tests on every deployment and a manual penetration test at least annually and after major changes, such as a new API version, a new user role or a payments flow. Authorization flaws tend to appear exactly when new features are layered on top of an existing codebase.
Conclusion
Most API incidents do not require sophisticated techniques: changing an ID, a field or a role the server never checks is enough. Start with an inventory, an authorization matrix and consumption limits, then validate with manual testing what tools cannot see. If you want us to assess your API or your app and its backend, explore our cybersecurity services or book a free consultation.