OWASP API Security Top 10 Complete Guide

OWASP — the Open Web Application Security Project — is a nonprofit organization that publishes widely adopted security standards and guidelines. The OWASP API Security Top 10 is a ranked list of the most critical security risks in modern APIs, based on data from real-world vulnerabilities, security reports, and community submissions. Understanding this list gives you a structured, prioritized framework for API security.

How to Use the OWASP API Security Top 10

The list serves three purposes:

1. Prioritization: Attack the most common and impactful risks first.
   Not all vulnerabilities are equal. BOLA (ranked #1) affects nearly
   every API. Focusing here gives the highest security ROI.

2. Communication: A shared vocabulary between developers, testers,
   managers, and executives. "We have an API1:2023 issue" is understood
   across the security industry.

3. Compliance: Regulatory frameworks and security assessments reference
   this list. Demonstrating coverage of OWASP Top 10 satisfies many
   audit requirements.

Current version: OWASP API Security Top 10 2023
  (Published 2023, reflecting modern API threats)

API1:2023 — Broken Object Level Authorization (BOLA)

Covered in depth: Topic 15

What it is:
  API endpoints expose object identifiers (IDs) and fail to verify
  whether the requesting user is authorized to access that specific object.

Attack example:
  GET /api/orders/9902  (attacker requests another user's order)
  → Server returns the order without checking ownership.

Impact: High
  Every object in the system is potentially accessible to any user.
  Complete data exposure of all users' data.

Remediation:
  ✓ Verify object ownership on every single request using server-side identity.
  ✓ Build ownership checks into database queries (WHERE owner_id = ?)
  ✓ Use UUIDs instead of sequential IDs.
  ✓ Monitor for sequential ID access patterns in logs.
  ✓ Write automated tests verifying cross-user access returns 403.

API2:2023 — Broken Authentication

Covered in depth: Topics 6, 7, 8, 9, 10

What it is:
  Authentication mechanisms are implemented incorrectly, allowing attackers
  to compromise tokens, impersonate users, or bypass authentication entirely.

Attack examples:
  - Accepting JWT with algorithm "none" (no signature verification)
  - Login endpoint with no rate limiting → credential stuffing
  - Tokens that never expire → stolen tokens valid forever
  - Weak random session token generation → predictable tokens

Impact: Critical
  Full account takeover. Admin impersonation.

Remediation:
  ✓ Never trust JWT "alg" header value. Hardcode expected algorithm.
  ✓ Validate all JWT claims: signature, expiry, issuer, audience.
  ✓ Rate limit authentication endpoints (5-10 attempts per minute per IP).
  ✓ Implement multi-factor authentication for privileged accounts.
  ✓ Set short token expiry (15-60 minutes for access tokens).
  ✓ Implement token revocation (blocklist or version check).

API3:2023 — Broken Object Property Level Authorization

Combines Excessive Data Exposure and Mass Assignment

Covered in depth: Topics 17 and 18

What it is:
  APIs either return too many properties (data exposure) or accept
  too many properties from clients and apply them (mass assignment).

Attack examples:
  Reading: GET /api/users/101 returns password_hash, internal_score, admin_flags.
  Writing: PATCH /api/users/101 { "role": "admin" } succeeds.

Impact: High
  Sensitive data exposure. Unauthorized privilege escalation.

Remediation:
  ✓ Return only properties needed for each specific endpoint and role.
  ✓ Use DTOs to define exactly which properties are acceptable in inputs.
  ✓ Add additionalProperties: false to request schemas.
  ✓ Never bind raw request bodies to data models.
  ✓ Test both read (are sensitive fields returned?) and write (are extra fields accepted?).

API4:2023 — Unrestricted Resource Consumption

Covered in depth: Topic 22

What it is:
  No limits on request rates, payload sizes, query complexity, or
  response sizes — allowing attackers to exhaust server resources
  or abuse business functionality at scale.

Attack examples:
  - 1,000,000 requests per minute → server crash (DoS)
  - 500 MB JSON body → memory exhaustion
  - GraphQL deeply nested query → database overload
  - 10,000 account registrations per hour to abuse signup bonuses

Impact: High
  Service unavailability. Financial loss from resource costs. Business fraud.

Remediation:
  ✓ Rate limit all endpoints. Stricter limits on sensitive operations.
  ✓ Set maximum request body size at gateway level.
  ✓ Limit GraphQL query depth and complexity scores.
  ✓ Set maximum page size for paginated list endpoints.
  ✓ Monitor for anomalous usage patterns.
  ✓ Implement CAPTCHA for high-abuse-risk endpoints.

API5:2023 — Broken Function Level Authorization (BFLA)

Covered in depth: Topic 16

What it is:
  APIs fail to enforce proper authorization checks at the function/endpoint
  level, allowing low-privilege users to access admin or privileged operations.

Attack examples:
  - Regular user calls DELETE /api/admin/users/101 → succeeds
  - Regular user accesses GET /api/admin/reports → gets all user data
  - Old v1 endpoint lacks role checks added in v2

Impact: High
  Unauthorized administrative actions. Data exposure. Account manipulation.

Remediation:
  ✓ Deny by default. Explicitly permit specific roles per endpoint.
  ✓ Test every endpoint with every role level.
  ✓ Test all HTTP methods on every URL.
  ✓ Restrict admin endpoints to internal network or VPN access only.
  ✓ Remove or secure all deprecated API versions.

API6:2023 — Unrestricted Access to Sensitive Business Flows

What it is:
  Business logic flows that should be rate-limited or human-verified
  are accessible to automation, enabling abuse at machine speed.

Attack examples:
  - Automated coupon code guessing: try all 6-digit codes in seconds
  - Mass account creation to abuse referral bonuses
  - Automated bulk ticket purchasing (scalping)
  - Automated loan application submission with synthetic identities
  - Voting fraud through automated ballot submission

Impact: High
  Financial fraud. Resource theft. Unfair advantage in competitive contexts.

Remediation:
  ✓ Identify which business flows have financial or competitive value.
  ✓ Apply business-logic-aware rate limiting (not just per-IP).
  ✓ Require CAPTCHA or device verification for high-value actions.
  ✓ Implement velocity checks: how many of this action has this account done today?
  ✓ Use device fingerprinting and behavioral analytics.
  ✓ Monitor for machine-speed patterns in business-critical flows.

API7:2023 — Server-Side Request Forgery (SSRF)

What it is:
  The API makes HTTP requests to URLs provided by the user, allowing
  attackers to reach internal services or cloud metadata endpoints
  not accessible from the internet.

Attack examples:
  POST /api/fetch-url { "url": "http://169.254.169.254/latest/meta-data/" }
  → API fetches AWS metadata endpoint, returns IAM credentials.
  
  POST /api/webhook { "url": "http://internal-db:5432/" }
  → API attempts to connect to internal database.

Impact: Critical
  Internal network access. Cloud credentials theft. RCE in severe cases.

Remediation:
  ✓ Validate all user-supplied URLs against a strict allowlist.
  ✓ Resolve DNS before validation (prevent DNS rebinding).
  ✓ Block requests to private IP ranges: 10.x, 172.16.x, 192.168.x, 169.254.x.
  ✓ Use a separate egress proxy for outbound requests from the API.
  ✓ Disable unnecessary URL-fetching functionality.
  ✓ Apply network egress controls to limit what the API server can reach.

API8:2023 — Security Misconfiguration

Covered across: Topics 19, 20, 24, 25

What it is:
  Insecure default configurations, incomplete configurations, misconfigured
  security headers, verbose error messages, or unnecessary features enabled.

Attack examples:
  - TLS 1.0 still enabled → vulnerable to POODLE attack
  - CORS: Access-Control-Allow-Origin: * → any website can call your API
  - Swagger UI enabled in production → complete API map for attackers
  - Server header reveals version: Apache/2.4.51 → targeted exploits
  - GraphQL introspection enabled in production → schema exposure
  - Default credentials unchanged: admin:admin on management interface

Impact: High
  Information leakage. Unauthorized access. Exploitation of known vulnerabilities.

Remediation:
  ✓ Disable TLS 1.0 and 1.1. Use TLS 1.2/1.3 only.
  ✓ Configure CORS with explicit allowlist.
  ✓ Disable Swagger UI and GraphQL introspection in production.
  ✓ Remove server version headers.
  ✓ Return generic error messages, not stack traces.
  ✓ Conduct regular security configuration reviews.
  ✓ Use infrastructure-as-code to enforce security configuration consistently.

API9:2023 — Improper Inventory Management

Covered in depth: Topic 26

What it is:
  Outdated API versions, shadow APIs, deprecated endpoints, or
  APIs exposed without proper security controls because they were
  unknown or forgotten.

Attack examples:
  - v1 API running without rate limiting added in v2
  - Development API exposed to the internet with no auth
  - Mobile app makes calls to an undocumented internal endpoint
  - Third-party integration endpoint forgotten for 3 years

Impact: High
  Exploitation of known vulnerabilities in unmaintained versions.
  Access to sensitive data through unprotected legacy endpoints.

Remediation:
  ✓ Maintain a complete, up-to-date API inventory.
  ✓ Define and enforce API deprecation policies with hard shutdown dates.
  ✓ All API versions must pass the same security standards.
  ✓ Require gateway registration for all APIs — undiscoverable internally = not deployed.
  ✓ Regularly scan for shadow APIs using network traffic analysis and code scanning.
  ✓ Apply the same patch and security review processes to all active versions.

API10:2023 — Unsafe Consumption of APIs

What it is:
  Developers trust data received from third-party APIs without proper
  validation, allowing compromised or malicious third-party data to
  cause security issues in the consuming application.

Attack examples:
  - Your API calls a partner's API for address verification.
    Partner API is compromised. Returns malicious data.
    Your API stores it without sanitization.
    The malicious data contains SQL injection → your DB is affected.

  - Your API fetches product descriptions from a supplier API.
    Supplier API is breached. Returns HTML with embedded scripts.
    Your app renders this HTML → XSS attack on your users.

  - Your API validates payment via a third-party service.
    Man-in-the-middle on the call to the third party.
    Attacker modifies response: "payment_status": "approved" (was "declined").
    Your app accepts a fraudulent payment.

Impact: High
  Third-party compromise becomes your compromise.

Remediation:
  ✓ Validate and sanitize ALL data received from third-party APIs.
    Treat them with the same distrust as user input.
  ✓ Use HTTPS with certificate validation for all third-party API calls.
  ✓ Define and enforce a schema for third-party responses.
  ✓ Conduct security due diligence on third-party API providers.
    Review their security certifications, incident history.
  ✓ Implement fallback behavior if a third-party API returns unexpected data.
  ✓ Monitor third-party API responses for anomalies.

OWASP API Security Top 10 — Complete Summary Matrix

Rank  │ Risk Name                              │ Primary Topics
──────┼────────────────────────────────────────┼────────────────────
API1  │ Broken Object Level Authorization      │ Topic 15
API2  │ Broken Authentication                  │ Topics 6, 7, 8, 9, 10
API3  │ Broken Object Property Level Auth      │ Topics 17, 18
API4  │ Unrestricted Resource Consumption      │ Topic 22
API5  │ Broken Function Level Authorization    │ Topic 16
API6  │ Unrestricted Sensitive Business Flows  │ Topic 22 + Design
API7  │ Server-Side Request Forgery (SSRF)     │ Topic 14 (via XXE SSRF)
API8  │ Security Misconfiguration              │ Topics 19, 20, 24, 25
API9  │ Improper Inventory Management          │ Topic 26
API10 │ Unsafe Consumption of APIs             │ Topic 21, 25

Building Your API Security Program

A mature API security program addresses all 10 risks systematically.

Quick Wins (implement within 1 month):
  - Enable HTTPS everywhere. Disable plain HTTP.
  - Add rate limiting to all endpoints via API gateway.
  - Validate JWT properly (signature, exp, iss, aud).
  - Return generic error messages. Remove stack traces.
  - Review CORS configuration. Remove wildcards.

Medium-Term Actions (1-3 months):
  - Conduct BOLA/BFLA testing across all endpoints.
  - Implement response shaping (return only needed fields).
  - Add input validation with schema enforcement.
  - Set up centralized logging and anomaly detection alerts.
  - Integrate SAST and DAST into CI/CD pipeline.

Long-Term Program (3-12 months):
  - Complete API inventory. Retire unused versions.
  - Implement API gateway with WAF for all production APIs.
  - Launch bug bounty or penetration testing program.
  - Train all developers in API security fundamentals.
  - Establish security review as part of API design process.
  - Publish responsible disclosure policy.

Key Points

  • BOLA (API1) is the most common API vulnerability — verify object ownership on every request using server-side identity.
  • Broken Authentication (API2) enables account takeover — validate JWTs completely, rate limit auth endpoints, use short token expiry.
  • Object Property Authorization (API3) covers both excessive data exposure and mass assignment — filter outputs and use DTOs for inputs.
  • SSRF (API7) lets attackers reach internal systems through your API — validate URLs against an allowlist and block private IP ranges.
  • Security Misconfiguration (API8) is often the easiest to fix — disable unnecessary features, enforce TLS, configure CORS explicitly.
  • Unsafe API Consumption (API10) reminds you that third-party API data must be treated as untrusted input — validate everything, regardless of source.
  • Build security in layers: quick wins immediately, systematic fixes over months, a mature ongoing security program as the destination.
Previous lessons
Back to courses

Leave a Comment