API Security Best Practices: The OWASP Top 10 Guide for 2025

APIs are the connective tissue of modern software. They handle authentication, move sensitive data, trigger payments, and power every integration your product depends on. When an API fails securely, the damage is contained. When it fails insecurely, it exposes user data, enables abuse, and creates liability that can take months to remediate.

The OWASP API Security Top 10 is the closest thing the industry has to a standardized checklist for what goes wrong with APIs and in what order. OWASP (Open Web Application Security Project) is a nonprofit foundation that publishes widely adopted security standards used by development teams, auditors, and compliance teams worldwide. The 2023 edition of their API Security Top 10 updated the list to reflect how API attack patterns have shifted, with new entries covering server-side request forgery (SSRF), API consumption abuse, and unsafe API integrations.

This guide uses the 2023 OWASP API Security Top 10 as its structure. For each risk, you will find a plain-language explanation of what it is, how attackers exploit it, and what concrete steps to take to close that gap.

Quick stat: Gartner predicted APIs would become the most frequent attack vector by 2022. Salt Security's 2023 State of API Security report found a 400% increase in unique API attackers year over year.

Key takeaways:

• The 2023 OWASP API Security Top 10 is the industry-standard framework for identifying and prioritizing API security risks
• Broken object-level authorization (BOLA) remains the top API risk and is responsible for most real-world data exposure incidents
• Authentication, rate limiting, input validation, and logging are the four pillars most teams need to strengthen first
• API security testing should be integrated into CI/CD pipelines, not treated as a one-time audit activity
• REST APIs remain the dominant architecture and require specific hardening steps distinct from GraphQL or gRPC

What is the OWASP API Security Top 10?

OWASP publishes Top 10 lists across several security domains. The API Security Top 10 focuses specifically on the risks most commonly exploited in API environments, distinct from the OWASP Web Application Top 10 that covers traditional web apps.

The 2023 list replaced the 2019 edition and reflects how attackers have adapted to the rise of API-first architectures. Several categories were renamed, merged, or added outright. The full 2023 list is:

1. API1:2023 Broken Object Level Authorization (BOLA)
2. API2:2023 Broken Authentication
3. API3:2023 Broken Object Property Level Authorization
4. API4:2023 Unrestricted Resource Consumption
5. API5:2023 Broken Function Level Authorization
6. API6:2023 Unrestricted Access to Sensitive Business Flows
7. API7:2023 Server Side Request Forgery (SSRF)
8. API8:2023 Security Misconfiguration
9. API9:2023 Improper Inventory Management
10. API10:2023 Unsafe Consumption of APIs

Each section below covers one risk in depth with specific countermeasures.

API1:2023 - Broken object level authorization (BOLA)

BOLA, also called Insecure Direct Object Reference (IDOR), is the most common and most damaging API vulnerability. It occurs when an API endpoint accepts an object identifier in a request (such as a user ID, order number, or document ID) and returns the corresponding object without properly verifying that the requesting user is authorized to access it.

In a typical BOLA attack, an authenticated user changes a parameter in a request from their own resource ID to another user's ID and receives data they should never see. The API processed the request correctly in a technical sense but failed the authorization check that should have been there.

Countermeasures

• Enforce object-level authorization checks on every API endpoint, not just at the route level
• Never rely on the client to determine which objects a user can access
• Use random, non-sequential identifiers (UUIDs) instead of incrementing integers to reduce enumeration risk
• Write automated tests that verify cross-user access attempts are rejected, not just that valid requests succeed

API2:2023 - Broken authentication

Authentication failures cover a wide range: weak token generation, missing expiration on tokens, improperly implemented OAuth flows, missing multi-factor authentication on sensitive endpoints, and credential stuffing vulnerabilities. The result in every case is that an attacker gains access to accounts or endpoints they should not reach.

Countermeasures

• Use industry-standard authentication protocols. OAuth 2.0 with PKCE is the current best practice for most API authentication flows
• Set short expiration windows on access tokens and use refresh token rotation
• Require MFA on any endpoint that accesses sensitive data, triggers payments, or modifies account settings
• Rate-limit authentication endpoints specifically, since credential stuffing attacks target login endpoints at high volume
• Store credentials using strong hashing functions (bcrypt, Argon2). Never store plaintext passwords or use MD5/SHA-1
• Rotate API keys on a schedule and revoke them immediately when team members leave. If you expose an API to developers, build a key management dashboard similar to what VEED's API platform offers, where keys can be issued and revoked per project

API3:2023 - Broken object property level authorization

This risk is new in the 2023 edition. It covers two related issues that were previously treated separately: excessive data exposure and mass assignment. Both stem from the API returning or accepting more object properties than the requesting user should have access to.

Excessive data exposure happens when an API response includes fields the client does not need or the user is not authorized to see, such as internal flags, admin fields, or other users' data embedded in a response. Mass assignment happens when an API accepts all object properties from a client without filtering, allowing an attacker to modify fields like user roles, pricing, or account status simply by including them in a request body.

Countermeasures

• Define explicit response schemas and filter output to include only the properties the requesting user needs
• Never return full database objects directly. Map to a defined response model on every endpoint
• Block mass assignment by explicitly allowlisting the properties that a given endpoint is permitted to modify
• Audit all POST and PATCH endpoints to confirm writable properties are restricted by role

API4:2023 - Unrestricted resource consumption

This replaces the 2019 "Lack of Resources and Rate Limiting" category and broadens it. Unrestricted resource consumption covers any scenario where an API allows a client to trigger disproportionate resource usage: server CPU, memory, storage, outbound network requests, third-party API calls, or financial costs.

A poorly rate-limited API endpoint that triggers a downstream third-party API call is a vector for both denial-of-service attacks and unexpected billing spikes, particularly relevant for teams building AI-powered APIs where each inference call carries a cost.

Countermeasures

• Apply rate limits at multiple levels: per IP, per API key, per user account, and per endpoint
• Set limits on request payload size, query complexity (for GraphQL), and response size
• Use token bucket or sliding window algorithms for rate limiting rather than fixed windows, which are easier to circumvent
• Return 429 Too Many Requests with a Retry-After header when limits are hit, so clients can back off gracefully
• Monitor and alert on consumption anomalies, especially on endpoints that trigger downstream costs
• If you are building on a video or AI API (such as VEED's Fabric API), confirm that the provider enforces rate limits at their end and build your own quota management layer on top to prevent runaway usage

API5:2023 - Broken function level authorization

Where BOLA is about accessing the wrong data object, broken function level authorization is about accessing the wrong endpoint or action altogether. This typically means a regular user can reach administrative or privileged API functions that should be restricted to specific roles.

Attackers often discover these endpoints by reviewing client-side JavaScript, mobile app binaries, or API documentation, then calling those endpoints directly without using the application UI.

Countermeasures

• Apply role-based access control (RBAC) at the function level, not just the object level
• Deny all requests to administrative endpoints by default and require explicit role grants
• Do not rely on obscurity: hiding admin endpoints at non-standard paths is not a security control
• Audit your API schema for any endpoints that perform privileged actions and confirm each one has role checks enforced in code, not just in UI controls

API6:2023 - Unrestricted access to sensitive business flows

This is a new entry in the 2023 list. It addresses API abuse scenarios that do not exploit technical vulnerabilities but instead misuse legitimate, functioning API endpoints at scale or in unintended sequences. Examples include bots scraping pricing data at high volume, automated scalping of limited-inventory items, bulk account creation for spam, and automated form submission or voting.

The API works as designed. The problem is that automated clients are using it in ways that harm the business or other users.

Countermeasures

• Identify which of your endpoints power business-critical flows and treat them as higher-risk even when they function correctly
• Add bot detection at these endpoints: CAPTCHA, device fingerprinting, behavioral analysis, or machine learning-based anomaly detection
• Enforce business logic constraints in the API layer, not just the UI. If a user should only be able to submit one form per day, enforce that server-side
• Monitor business flow metrics, not just technical metrics. A spike in checkout-page API calls from a single account is an abuse signal even if no rate limit is technically exceeded

API7:2023 - Server side request forgery (SSRF)

SSRF is also new in 2023, elevated from broader web application coverage. It occurs when an API accepts a URL or network location as input and makes a server-side request to it without validating where that request goes. An attacker can point the API at internal services (cloud metadata endpoints, internal admin panels, databases) that should never be reachable from the public internet.

SSRF attacks are particularly dangerous in cloud environments because the AWS, GCP, and Azure instance metadata endpoints (such as 169.254.169.254 on AWS) can return credentials and configuration data that allow an attacker to escalate to full cloud account access.

Countermeasures

• Validate and allowlist acceptable URL schemes, hosts, and ports before making server-side requests
• Block requests to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.1, 169.254.x.x) at the network level
• Disable HTTP redirects in server-side HTTP clients or validate the redirect destination before following
• Use a dedicated egress proxy or firewall rule to restrict what internal services the application server can reach

API8:2023 - Security misconfiguration

Misconfiguration is the broadest category and the one that catches teams who have done everything else right. It covers missing security headers, exposed debug endpoints, permissive CORS policies, default credentials left in place, unencrypted transmissions, verbose error messages that leak stack traces, and outdated TLS configurations.

Countermeasures

• Enforce TLS 1.2 or higher on all API endpoints. Reject connections using deprecated protocols (TLS 1.0, 1.1, SSL)
• Set security headers on all API responses: Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Content-Security-Policy
• Configure CORS to allowlist specific origins rather than using wildcard (*)
• Return generic error messages to clients. Log verbose error details server-side, not in API responses
• Remove or disable all debug, admin, and test endpoints before deploying to production
• Run your API configuration through an automated scanner before each deployment as part of your CI/CD pipeline

API9:2023 - Improper inventory management

APIs accumulate over time. Old versions get deprecated but not decommissioned. Internal APIs get exposed accidentally. Shadow APIs, built by teams outside the central API program, appear without security review. All of these endpoints exist in your attack surface even if no one is actively maintaining them.

Attackers specifically target older API versions because they often predate security improvements and rate limiting controls that were added later.

Countermeasures

• Maintain a complete, up-to-date API inventory that includes version, owner, authentication requirements, and production status
• Decommission deprecated API versions on a published timeline and enforce sunset dates
• Apply the same security controls to all API versions, not just the current one
• Use API gateway tooling to discover shadow APIs by monitoring network traffic for unregistered endpoints
• Include API documentation review in your security audit process

API10:2023 - Unsafe consumption of APIs

The final entry in the 2023 list is also new and addresses a risk that has grown as API-first architectures have become standard. Your API security posture is only as strong as the third-party APIs you consume. If your application trusts and processes data from a third-party API without validation, an attacker who compromises that third-party service can use it as a vector into your system.

This is not a theoretical risk. Supply chain attacks via compromised APIs have caused significant incidents across SaaS, fintech, and healthcare sectors.

Countermeasures

• Treat third-party API responses the same way you treat user input: validate, sanitize, and never trust implicitly
• Define what valid responses from each third-party API look like and reject or flag responses that fall outside those parameters
• Use webhook signature verification on all inbound webhooks from third parties
• Monitor third-party API dependencies for security advisories and version updates
• Store third-party API credentials in a secrets manager, rotate them regularly, and scope them to minimum required permissions

API security testing: a practical checklist

Knowing the risks is the starting point. Testing systematically is what keeps you ahead of them. The following checklist covers the minimum testing activities your team should run before any API reaches production and on a recurring basis afterward.

Authentication and authorization tests

• Attempt cross-user object access using valid credentials from a separate test account (BOLA test)
• Test every privileged endpoint with a lower-privilege token to confirm function-level authorization holds
• Attempt to modify read-only fields through POST/PATCH requests (mass assignment test)
• Test token expiration behavior: confirm expired tokens are rejected, not silently accepted
• Confirm that invalidated or rotated API keys return 401, not stale cached responses

Input and request validation tests

• Submit oversized payloads to confirm size limits are enforced and do not cause application errors
• Test for SQL injection, NoSQL injection, and command injection in all string parameters
• Test URL and file path parameters for path traversal attempts
• Submit malformed JSON and XML to confirm error handling does not expose stack traces
• Test GraphQL endpoints for query complexity limits and introspection access in production

Rate limiting and abuse tests

• Confirm authentication endpoints return 429 after a defined number of failed attempts
• Test whether rate limits reset correctly at the defined interval
• Check whether rate limits apply per API key, per IP, or both, and confirm the behavior matches your policy

Transport and configuration tests

• Verify all endpoints enforce HTTPS and reject plaintext HTTP requests
• Confirm TLS version and cipher suite configuration using a tool like testssl.sh or SSLLabs
• Check all response headers for required security headers
• Test CORS configuration by sending requests from an unauthorized origin
• Scan for any endpoints returning verbose debug output or internal path information

Integrating tests into CI/CD

Manual security testing catches known patterns but misses regressions introduced between release cycles. The most effective teams integrate automated API security scanning into their CI/CD pipelines so every code change is checked before it reaches production.

• Tools like OWASP ZAP, Burp Suite, and 42Crunch can run automated API security scans against OpenAPI/Swagger specs
• Run security scan jobs as a pipeline stage that blocks deployment on critical findings
• Maintain a baseline of expected security scan results and alert on any new findings
• Schedule recurring scans of your production API separate from deployment-triggered scans, since configuration drift can introduce vulnerabilities between deployments

Beyond the checklist: API security governance

The OWASP Top 10 covers individual vulnerabilities. Governance covers the organizational structures that prevent those vulnerabilities from being introduced in the first place.

• API design standards: Define and enforce API design guidelines that include security requirements, such as mandatory authentication on all endpoints, required response schemas, and standardized error formats
• Security review gates: Require a security review before any new API or significant API change goes to production. This does not need to be a lengthy process, but it should be a defined step with a checklist
• API inventory ownership: Assign an owner to every API in your inventory. Unowned APIs are the ones that get left running after they should have been decommissioned
• Incident response playbook: Have a documented process for what happens when an API security incident is detected, including who is notified, how the endpoint is isolated, and how the investigation is conducted‍
• Developer training: API security knowledge should be distributed across your engineering team, not siloed in a security team. Regular training on the OWASP API Top 10 reduces the rate at which these vulnerabilities are introduced at the code level

Putting it all together

API security is not a one-time project. It is a set of controls you build into every layer of your stack and revisit every time your API changes. The OWASP API Security Top 10 gives you a clear, prioritized framework for where to focus: start with authorization (BOLA and function-level), then authentication, then input validation and rate limiting, then configuration and inventory.

The teams that manage this well share a few common practices. They treat security testing as a pipeline step, not a pre-launch scramble. They maintain a live API inventory with named owners. They apply the same controls to every API version, not just the current one. And they design their APIs with an attacker's perspective from the start, asking "what happens if someone sends this endpoint unexpected input or calls it from a different account?" before the code ships.

If you are building on or consuming a third-party API as part of your product, those same principles apply to how you integrate. Whether you are working with a payment processor, an identity provider, or a video generation API like VEED's Fabric API, validate responses, scope credentials to minimum permissions, and monitor consumption. The security posture of your product includes every API it depends on.

Use the checklist in this guide as your starting audit. Work through the OWASP list top to bottom, close the gaps you find, and build the governance structures that prevent them from reopening.