Top 12 Common API Vulnerabilities Every Tester Should Know

https://sl4x0.github.io/api-notes/common-api-vulnerablities/

Introduction

This guide enumerates the most common API vulnerabilities, explains why they matter, and provides practical examples and testing techniques for security professionals.

Information Disclosure

APIs may unintentionally expose sensitive data in responses or public sources such as code repositories, search results, news, social media, or public API directories. For example, a WordPress site might reveal user details via GET https://www.sitename.org/wp-json/wp/v2/users returning JSON objects with usernames and slugs. Attackers can reuse these slugs for credential‑stuffing or password‑spraying attacks.

Broken Object‑Level Authorization (BOLA)

When an API allows a user to access resources they are not authorized for, a BOLA flaw exists. An attacker can guess or enumerate identifiers (e.g., user IDs) and request data for other users. Example request and response:

{
  "id": "5501",
  "first_name": "Cloud",
  "last_name": "Strife",
  "link": "https://www.bestgame.com/user/strife.buster.97",
  "name": "Cloud Strife",
  "dob": "1997-01-31",
  "username": "strife.buster.97"
}

Pattern‑based ID guessing often reveals additional accounts, and a few requests can confirm the vulnerability.

Broken Authentication

Weak or missing authentication mechanisms let attackers impersonate users. RESTful APIs should be stateless and require a token obtained after registration. If token generation lacks sufficient randomness, attackers may predict or hijack tokens. Hard‑coded tokens in JavaScript, insecure password‑reset flows, or default credentials also lead to compromise.

Over‑Exposed Data

Endpoints that return more information than necessary expose unnecessary fields. A request such as GET /api/v3/account?name=Cloud+Strife might return a full user object, including privileged fields and related accounts, enabling further attacks.

{
  "id": "5501",
  "first_name": "Cloud",
  "last_name": "Strife",
  "privilege": "user",
  "representative": [
    {
      "name": "Don Corneo",
      "id": "2203",
      "email": "[email protected]",
      "privilege": "super-admin",
      "admin": true,
      "two_factor_auth": false
    }
  ]
}

Lack of Rate Limiting

Without proper rate limits, an API can be flooded with requests, leading to denial‑of‑service conditions or enabling brute‑force attacks. Testers should try adding parameters, switching clients, or changing IP addresses to see if limits can be bypassed.

Broken Function‑Level Authorization (BFLA)

BFLA occurs when a user can invoke API functions reserved for higher‑privilege roles. Unlike BOLA, the issue concerns actions rather than data. Detect BFLA by examining admin API documentation and sending privileged‑action requests as a non‑privileged user.

Mass Assignment

If an API accepts parameters beyond the intended whitelist, attackers can modify attributes such as isAdmin during account creation:

// Example payload to create an admin account
{
  "User": "scuttleph1sh",
  "Password": "GreatPassword123",
  "isAdmin": true
}

Discover such flaws by reviewing API documentation for unexpected fields and injecting them into requests.

Security Misconfiguration

Common misconfigurations include insecure headers, missing TLS, default credentials, and unnecessary HTTP methods. Example insecure response headers:

HTTP/1.1 200 OK
X-Powered-By: VulnService 1.11
X-XSS-Protection: 0
X-Response-Time: 566.43

Missing TLS allows plaintext interception; default accounts enable immediate privileged access.

Injection

When input is not properly sanitized, payloads can reach backend systems. A classic SQL injection example:

POST /api/v1/register HTTP/1.1
{
  "Fname": "hAPI",
  "Lname": "Hacker",
  "Address": "' OR 1=0--"
}

Another case reads arbitrary files via a query parameter, exposing /etc/passwd contents.

Asset Mismanagement

Exposing deprecated, development, or undocumented endpoints leads to additional vulnerabilities such as over‑exposure, missing rate limits, or injection. Track versioned endpoints (e.g., /api/v1/, /api/v2/) and test inactive versions for weaknesses.

Business Logic Flaws

These flaws exploit intended functionality in unintended ways, such as bypassing multi‑factor authentication by setting MFA=false or uploading arbitrary files without validation. Detect them by reviewing API specifications for statements like “only admins may perform X” and testing violations.

Conclusion

Familiarity with these API vulnerabilities enables testers to efficiently discover, exploit, and report issues, helping organizations harden their services against real‑world attacks.