Back to Blog
Cybersec Weekly: API security: OWASP top 10 for APIs explaine
🤖 AI Generated · Auto-published via GitHub Actions
🔐 Cybersecurity Weekly

Cybersec Weekly: API security: OWASP top 10 for APIs explaine

22 June 2026 7 min read Aswin Mathew
cybersecurityweeklysecurity

Hook — why this matters right now

APIs have become the backbone of modern applications, powering everything from mobile apps to microservices and IoT devices. As organisations accelerate digital transformation, the attack surface expands dramatically, making API security a top priority for developers and security teams alike. In 2024, over 60% of reported data breaches involved abused or misconfigured APIs, highlighting the urgent need to understand and mitigate the most common weaknesses.

Technical explanation of the concept or threat

The OWASP API Security Top 10 is a community‑driven list that outlines the most critical risks specific to application programming interfaces. Unlike the classic OWASP Top 10 for web applications, this list focuses on issues such as broken object level authorization, excessive data exposure, lack of rate limiting, and improper assets management. Each item represents a distinct class of vulnerability that attackers can exploit to gain unauthorized access, exfiltrate data, or disrupt service.

API1:2023 – Broken Object Level Authorization (BOLA)

BOLA occurs when an API endpoint uses user‑supplied input to access objects without verifying that the requester is entitled to that object. For example, a request to GET /users/{id}/profile might return another user's profile if the id parameter is not checked against the authenticated user's identity.

API2:2023 – Broken Authentication

Weak authentication mechanisms — such as predictable tokens, missing expiration, or insufficient transport protection — allow attackers to compromise user accounts or impersonate legitimate clients. Common flaws include JWTs signed with weak secrets or tokens transmitted over HTTP.

API3:2023 – Excessive Data Exposure

APIs often return more data than necessary, relying on clients to filter the response. Sensitive fields like passwords, payment details, or internal identifiers may be exposed in the response body, enabling data leakage even when the endpoint itself is properly authorized.

API4:2023 – Lack of Resources & Rate Limiting

Without limits on the number of requests a client can make within a time window, APIs become vulnerable to denial‑of‑service attacks, brute‑force credential stuffing, and business logic abuse (e.g., unlimited price‑checking).

API5:2023 – Broken Function Level Authorization

This vulnerability mirrors traditional privilege escalation: an API exposes administrative or privileged functions to lower‑privileged users because the authorization checks are missing or incorrectly implemented at the operation level.

API6:2023 – Unrestricted Access to Sensitive Business Flows

Business‑critical flows such as “place order” or “redeem coupon” may be exposed without adequate anti‑automation controls, allowing attackers to script abuse that impacts revenue or inventory.

API7:2023 – Server Side Request Forgery (SSRF)

APIs that fetch remote resources based on user‑supplied URLs can be tricked into making internal requests, exposing metadata services, internal APIs, or cloud‑instance metadata (e.g., AWS EC2 IAM credentials).

API8:2023 – Security Misconfiguration

Common misconfigurations include verbose error messages, unnecessary HTTP methods enabled (e.g., PUT, DELETE on public endpoints), outdated software components, and cloud storage buckets left publicly accessible.

API9:2023 – Improper Inventory Management

Undocumented or deprecated API versions, shadow APIs, and exposed debug endpoints create an inventory gap that attackers can exploit. Maintaining an accurate, up‑to‑date API catalog is essential for effective security monitoring.

API10:2023 – Unsafe Consumption of Third‑Party APIs

When your application integrates external APIs, insufficient validation of responses or blind trust in third‑party data can lead to injection attacks, data poisoning, or unintended privilege escalation.

Real-world examples or recent incidents (realistic plausible)

In early 2024, a fintech startup suffered a breach when attackers exploited a BOLA flaw in its transaction API. By simply changing the accountId parameter in a GET request, they retrieved transaction histories for thousands of users, leading to reputational damage and regulatory fines.

A large e‑commerce platform experienced a credential stuffing campaign after its login API lacked rate limiting. Attackers used a botnet to test millions of credential pairs, successfully hijacking accounts and making fraudulent purchases before the anomaly was detected.

During a red‑team exercise, a security team discovered an SSRF vulnerability in an internal metadata API that accepted a url query parameter. By supplying http://169.254.169.254/latest/meta-data/iam/security-credentials/, they retrieved temporary AWS credentials, which were then used to spin up illicit EC2 instances for cryptocurrency mining.

A healthcare provider exposed patient health information through an API that returned full medical records in response to a simple /patients/{id} call, even though the endpoint was intended to return only demographic data. The excessive data exposure was traced to a missing field‑level filter in the service layer.

Step-by-step technical breakdown with code/terminal commands

The following sections illustrate how to test for two of the most prevalent API vulnerabilities: BOLA and missing rate limiting. All examples assume you have a test API running locally at http://127.0.0.1:8080 and that you possess a valid JWT token for a low‑privilege user.

# 1. Store a valid JWT for a regular user (user_id=42)
TOKEN="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0MiIsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzE1MDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"

# 2. Attempt to access another user's profile (user_id=99) – BOLA test
curl -i -H "Authorization: Bearer $TOKEN" \
     "http://127.0.0.1:8080/api/v1/users/99/profile"

# Expected outcome if vulnerable: HTTP 200 with the target user's data
# If properly protected: HTTP 403 Forbidden or 404 Not Found

The command above demonstrates a straightforward BOLA check. If the API returns the profile for user 99, the authorization layer is broken. To defend against this, implement a middleware that extracts the user ID from the token and compares it to the requested resource identifier before proceeding.

Pro tip: Use a centralized authorization service (e.g., OPA or AWS Verified Permissions) to enforce object‑level checks consistently across all endpoints.

Testing for missing rate limiting

Rate limiting deficiencies can be uncovered with a simple loop that sends rapid requests and observes the response codes.

# 3. Baseline: obtain a token for a test user
TOKEN="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIzIiwiaWF0IjoxNzE1MDAwMDAwfQ.abc123"

# 4. Send 20 rapid login attempts to the /auth/token endpoint
for i in {1..20}; do
  curl -s -o /dev/null -w "%{http_code}\n" \
       -H "Content-Type: application/json" \
       -d '{"username":"testuser","password":"wrongpass"}' \
       "http://127.0.0.1:8080/auth/token"
done

# Look for patterns: if most responses are 200 (success) or 401 without delay,
# the API likely lacks rate limiting or lockout mechanisms.

If the API returns 200 or 401 for every attempt without throttling, an attacker can brute‑force credentials at scale. Mitigation strategies include implementing leaky bucket or fixed window counters, returning 429 Too Many Requests when thresholds are exceeded, and integrating with an API gateway or WAF that provides built‑in throttling.

Defence and mitigation strategies

Securing APIs requires a layered approach that combines secure design, rigorous testing, and runtime protection. Below are actionable controls mapped to each OWASP API Top 10 item.