Kapitel 3: API Insecurities

Understanding common API vulnerabilities is essential for effective penetration testing and defense strategies. This chapter dives into real-world issues found in REST APIs, following the OWASP API Security Top 10, along with other critical weaknesses that often go overlooked.

🧨 Information Disclosure

APIs may unintentionally leak sensitive data to unauthenticated or low-privilege users via:

• Verbose error messages
• Public endpoints
• Misconfigured logs or debug data
• Incomplete access control

Request:

1GET https://sitename.org/wp-json/wp/v2/users

Returns:

1[
2{"id": 1, "name": "Administrator", "slug": "admin"},
3{"id": 2, "name": "Vincent Valentine", "slug": "Vincent"}
4]

These usernames ("slugs") can be used in brute-force or password-spraying attacks.

🔓 Broken Object Level Authorization (BOLA)

Occurs when APIs allow users to access objects that belong to others.

1GET /api/users?id=5501 // Your account
2GET /api/users?id=5502 // Someone else’s

If no access control is in place, attackers can enumerate and access other users' data.

🚫 Broken User Authentication

Issues with API auth mechanisms such as:

• Weak or predictable tokens
• Hardcoded API keys in frontend code
• Missing multi-factor auth
• Brute-forceable endpoints

1const API_KEY = "abc123-hardcoded-key";

📦 Excessive Data Exposure

API responses contain more information than needed.
Example:

1GET /api/account?name=Cloud

Returns:

1{
2"name": "Cloud",
3"privilege": "user",
4"admin": true,
5"two_factor_auth": false,
6"created_by": {
7  "name": "Don Corneo",
8  "privilege": "super-admin"
9}
10}

This hands sensitive data to anyone who queries the endpoint—even if they shouldn’t see it.

🚨 Lack of Resources & Rate Limiting

APIs that don’t limit request volume risk:

• DoS attacks
• Brute-force abuse
• Excessive infrastructure cost

Always verify 429 Too Many Requests responses and check for bypasses (IP rotation, headers, etc.).

🛂 Broken Function Level Authorization (BFLA)

When users can invoke admin-only functions via:

• Undocumented endpoints
• Changing request methods (e.g., PUT instead of GET)
• Fuzzing HTTP verbs

Example:

1POST /admin/users/create
2Authorization: Bearer token-of-regular-user

🧬 Mass Assignment

APIs that don’t validate input fields allow users to manipulate sensitive data.

1{
2"user": "attacker",
3"password": "123456",
4"isAdmin": true
5}

If the backend accepts this blindly, a regular user can escalate privileges.

⚙️ Security Misconfigurations

• Missing or misconfigured headers (e.g., X-XSS-Protection: 0)
• Verbose server responses (X-Powered-By: VulnService 1.1)
• Outdated services exposed
• Weak TLS configs

These provide an attacker with metadata that can be leveraged for exploits.

💉 Injection Vulnerabilities

Includes:

• SQL Injection
• Command Injection
• LDAP Injection
• XPath Injection

Example:

1GET /api/books?show=/etc/passwd

Response:

1root:x:0:0:root:/root:/bin/bash
2...

If input isn’t sanitized, attackers can access files or execute commands.

🧱 Improper Assets Management

Refers to:

• Unpatched legacy APIs (/api/v1/)
• Test environments left exposed (/demo, /uat)
• Forgotten staging endpoints

Old APIs often lack current security measures. Always test multiple versions.

🧠 Business Logic Vulnerabilities (BLFs)

Flaws in how API features are implemented:

• Assume users won’t abuse certain functions
• Trust frontend enforcement
• Rely on security by obscurity

Example:

1POST /api/login
2Body: {
3"username": "user",
4"password": "pw",
5"MFA": false // bypassed
6}

If the backend trusts the MFA parameter without validation, attackers can bypass multi-factor authentication.

Test for BLFs manually—automated scanners won’t detect logic flaws.