OWASP API Security Top 10 (2019)

Comprehensive Analysis & Security Guidelines

1. Broken Object Level Authorization (BOLA)

Overview

Broken Object Level Authorization is consistently ranked as one of the most critical API security vulnerabilities. This issue occurs when an API fails to properly validate that a user has permission to access a specific object or resource. Attackers can exploit this by manipulating object identifiers in API requests to gain unauthorized access to data belonging to other users.

Why It's Critical

BOLA affects direct access to data within the API layer. Unlike traditional web applications where authorization checks might be enforced at multiple layers, APIs often expose direct object references, making them particularly vulnerable. The impact is severe: unauthorized data access, privacy breaches, and potential regulatory violations.

Real-World Attack Scenario

E-Commerce Order Access Vulnerability:

Consider an e-commerce platform that exposes an endpoint for retrieving order details:

GET /api/orders/12345

An attacker logs in as a legitimate customer and receives their order ID (12345). They then systematically modify the order ID to access other customers' orders:

GET /api/orders/12346 GET /api/orders/12347 GET /api/orders/12348

If the API doesn't verify that the authenticated user owns the requested order, the attacker gains access to sensitive information including customer names, addresses, purchase history, and payment details.

Attack Flow Diagram
Attacker
Authenticates
→
Receives
Object ID
→
Modifies
ID Parameter
→
Accesses
Unauthorized Data
Remediation Strategies
  • Server-Side Authorization Checks: Implement robust authorization checks that verify the authenticated user has permission to access the requested object before returning any data.
  • Use Non-Sequential Identifiers: Replace predictable sequential IDs (123, 124, 125) with UUIDs or other non-guessable identifiers (e.g., 7f3d92a1-8b4c-4e7d-9f2a-5c8e6b1d4a3f).
  • Implement Access Control Lists (ACLs): Maintain explicit relationships between users and objects they can access.
  • Rate Limiting: Implement rate limiting to detect and prevent systematic enumeration attempts.
// Example authorization check in Node.js if (order.userId !== authenticatedUser.id) { return res.status(403).json({ error: "Unauthorized" }); }

2. Excessive Data Exposure & Mass Assignment Intersection

Understanding the Vulnerabilities

Excessive Data Exposure occurs when an API returns more information than necessary in its responses. Developers might expose entire database objects without filtering sensitive fields, assuming client-side filtering will handle it.

Mass Assignment involves automatically mapping all incoming request fields to internal data models without proper filtering. This allows attackers to modify fields that should be read-only or restricted.

⚠️ The Dangerous Intersection

When these vulnerabilities combine, they create a critical security loophole:

  1. An attacker calls an API endpoint and receives excessive data in the response, revealing hidden or internal fields.
  2. They discover fields like "isAdmin", "accountBalance", or "roleId" that weren't intended to be visible.
  3. Using mass assignment, they craft a request including these discovered fields to escalate privileges or manipulate restricted attributes.
Combined Attack Example

Step 1 - Excessive Data Exposure:

GET /api/users/profile Response: { "name": "John", "email": "[email protected]", "isAdmin": false, "credits": 100 }

Step 2 - Mass Assignment Exploitation:

PUT /api/users/profile Body: { "name": "John", "isAdmin": true, "credits": 999999 }

If the API doesn't validate which fields can be modified, the attacker successfully escalates to administrator privileges and adds unlimited credits.

Vulnerability Intersection Flow
API Returns
Full Object
→
Attacker
Discovers Fields
→
Crafts Malicious
Update Request
→
Privilege
Escalation
Comprehensive Mitigation Strategy

1. Implement Data Transfer Objects (DTOs)

Separate internal data models from API input/output schemas to control exactly what data is exposed and accepted.

// Response DTO - only expose safe fields class UserResponseDTO { public string Name { get; set; } public string Email { get; set; } // isAdmin and credits are NOT included }

2. Explicit Whitelisting

Define exactly which fields can be modified in each API endpoint.

// Request DTO - only allow safe updates class UserUpdateDTO { public string Name { get; set; } public string Email { get; set; } // Restricted fields cannot be updated via this endpoint }

3. Field-Level Security

  • Mark sensitive fields as read-only at the model level
  • Implement attribute-based access control for field-level permissions
  • Use separate endpoints for privileged operations (e.g., /api/admin/users/promote)

4. Response Filtering

// Example: Filter response before sending const safeFields = ['name', 'email', 'createdAt']; const filteredResponse = _.pick(userObject, safeFields); return res.json(filteredResponse);

3. Robust Logging & Monitoring for Financial APIs

The Critical Need for Visibility

Insufficient logging and monitoring is particularly dangerous in APIs handling sensitive financial transactions. Without proper visibility, security incidents can go undetected for extended periods, resulting in significant financial losses, regulatory penalties, and reputational damage.

⚠️ Industry Statistics: According to IBM's Cost of a Data Breach Report, it takes an average of 287 days to identify and contain a breach. Proper logging and monitoring can dramatically reduce this time window.

Comprehensive Logging Strategy

What to Log
  • Authentication Events: Login attempts (successful and failed), logout events, token generation and revocation
  • Authorization Failures: Attempts to access restricted resources or perform unauthorized actions
  • Financial Transactions: Payment initiation, completion, failures, refunds, and cancellations
  • Data Access: Who accessed what data, when, and from where
  • Configuration Changes: Modifications to security settings, user roles, or system configurations
  • Account Modifications: Changes to account details, passwords, payment methods, or security settings
Structured Log Entry Example
{ "timestamp": "2026-03-28T10:15:30Z", "eventType": "PAYMENT_INITIATED", "userId": "usr_7f3d92a1", "ipAddress": "192.168.1.100", "amount": 1500.00, "currency": "USD", "recipientId": "usr_8b4c5e7d", "sessionId": "sess_9f2a5c8e", "userAgent": "Mozilla/5.0...", "status": "SUCCESS" }
Monitoring & Alert Pipeline
API
Events
→
Structured
Logging
→
SIEM
Analysis
→
Real-Time
Alerts
→
Incident
Response
Implementation Best Practices

1Define Suspicious Patterns

  • Multiple failed login attempts from same IP within short timeframe
  • Successful login from unusual geographic location
  • Large financial transactions outside normal user behavior patterns
  • Rapid succession of account changes
  • Access attempts outside business hours

2Implement Automated Alerting

// Example alert rule configuration if (failedLoginCount > 5 && timeWindow < 5minutes) { sendAlert("SECURITY", "Potential brute force attack"); blockIP(sourceIP, duration: "30minutes"); }

3Protect Sensitive Data in Logs

  • Never log passwords, even in hashed form
  • Mask credit card numbers (show only last 4 digits)
  • Encrypt logs containing personally identifiable information (PII)
  • Redact social security numbers, account numbers, and API keys
// Example: Masking sensitive data const maskedCard = cardNumber.slice(-4).padStart(cardNumber.length, '*'); logger.info(`Payment processed for card: ${maskedCard}`);

4Integrate with SIEM Tools

Couple logs with Security Information and Event Management (SIEM) systems for real-time monitoring and correlation:

  • Splunk, ELK Stack (Elasticsearch, Logstash, Kibana)
  • IBM QRadar, Microsoft Sentinel
  • AWS CloudWatch, Azure Monitor

5Establish Retention Policies

  • Retain security logs for minimum 90 days (industry standard)
  • Archive critical logs for 1-7 years (compliance requirements)
  • Implement secure, tamper-proof log storage
  • Regular backup and disaster recovery testing

4. Manual Penetration Testing Methodology

Overview

Manual penetration testing remains crucial for identifying API vulnerabilities that automated tools might miss. This section provides step-by-step methodologies for testing two critical OWASP API Top 10 vulnerabilities.

Testing: Broken Function Level Authorization

What It Is

Broken Function Level Authorization occurs when an API fails to properly validate user privileges for specific functions or endpoints. Regular users might be able to access administrative functions simply by knowing or guessing the endpoint URL.

Step-by-Step Testing Process

1Reconnaissance & Endpoint Discovery

Identify all API endpoints and their intended privilege levels:

GET /api/users - Public endpoint GET /api/admin/users - Admin-only endpoint DELETE /api/admin/users/123 - Admin-only function POST /api/manager/reports - Manager-level endpoint

Use tools like Burp Suite, API documentation, or JavaScript source code analysis to discover endpoints.

2Establish Baseline Access

Create test accounts with different privilege levels:

  • Regular user account
  • Manager/supervisor account (if applicable)
  • Administrator account

Document which endpoints each role can legitimately access.

3Authenticate as Low-Privileged User

Log in as a regular user and capture the authentication token:

POST /api/auth/login Body: {"username": "regularuser", "password": "password123"} Response: {"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}
4Attempt Privileged Operations

Using the regular user's token, attempt to access admin-only endpoints:

GET /api/admin/users Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
DELETE /api/admin/users/456 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
POST /api/admin/config/update Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... Body: {"setting": "maintenance_mode", "value": true}
5Analyze Server Responses

Document the API's behavior:

  • Success (200/201): Vulnerability confirmed - unauthorized access granted
  • Forbidden (403): Proper authorization in place
  • Unauthorized (401): Authentication required but not role-based
  • Not Found (404): Endpoint might be protected or non-existent
⚠️ Testing Note: A 404 response doesn't always mean security is properly implemented. The endpoint might exist but return 404 as a security-by-obscurity measure.
6Test HTTP Method Manipulation

Sometimes authorization checks are method-specific:

GET /api/admin/users - Returns 403 Forbidden POST /api/admin/users - Might be unprotected PUT /api/admin/users - Test this as well PATCH /api/admin/users - Don't forget alternative methods
7Document and Report

For each successful unauthorized access, document:

  • Exact endpoint URL and HTTP method
  • Authentication credentials used
  • Expected vs. actual response
  • Potential impact (data exposure, privilege escalation, etc.)
  • Proof-of-concept screenshots or response captures
8Escalate to Development Team

Provide clear remediation recommendations:

  • Implement role-based access control (RBAC) at all endpoints
  • Verify user roles server-side before executing privileged operations
  • Use middleware or decorators to enforce authorization consistently
  • Apply principle of least privilege
Testing: Injection Vulnerabilities

What It Is

Injection vulnerabilities occur when untrusted data is sent to an interpreter as part of a command or query. Common types include SQL injection, NoSQL injection, command injection, and LDAP injection. These can lead to data breaches, data manipulation, or complete system compromise.

Step-by-Step Testing Process

1Identify Input Vectors

Locate all user-controllable input fields in API requests:

  • Query parameters: ?search=keyword&category=electronics
  • Request body (JSON/XML): {"username": "test", "email": "[email protected]"}
  • Headers: X-Custom-Header: value
  • Path parameters: /api/users/123/orders
2Test SQL Injection

Insert SQL injection payloads into identified input fields:

Basic SQL Injection Payloads:

GET /api/products?category=electronics' OR '1'='1 GET /api/users?id=1' UNION SELECT NULL,username,password FROM users-- POST /api/login Body: {"username": "admin'--", "password": "anything"}

Time-Based Blind SQL Injection:

GET /api/products?id=1' AND SLEEP(5)-- GET /api/products?id=1' WAITFOR DELAY '00:00:05'--

If the server response is delayed by 5 seconds, SQL injection is present.

Boolean-Based Blind SQL Injection:

GET /api/products?id=1' AND 1=1-- (Returns normal response) GET /api/products?id=1' AND 1=2-- (Returns different response)

Different responses indicate the SQL query is being executed.

3Test NoSQL Injection

For APIs using MongoDB or other NoSQL databases:

POST /api/login Body: {"username": {"$ne": null}, "password": {"$ne": null}}
GET /api/users?filter={"$where": "this.username == 'admin'"}
POST /api/search Body: {"query": {"$gt": ""}}
4Test Command Injection

If the API executes system commands (e.g., file processing, network utilities):

POST /api/convert Body: {"filename": "document.pdf; cat /etc/passwd"}
GET /api/ping?host=127.0.0.1; whoami
POST /api/backup Body: {"path": "/var/data`id`"}
5Monitor API Responses

Look for indicators of successful injection:

  • Database Error Messages: SQL syntax errors, database names, table names
  • Unexpected Data: Data from other users or tables appearing in response
  • Timing Anomalies: Delayed responses indicating time-based injection
  • Command Output: System information, file contents, or command results
  • Behavioral Changes: Different response content based on injected logic
Example Error Message Indicating SQL Injection
Response: { "error": "You have an error in your SQL syntax near '' OR '1'='1' at line 1" }
6Check Server Logs

If you have access to server logs (in authorized testing), examine:

  • Application logs for error messages
  • Database logs for malformed queries
  • System logs for executed commands
  • Web server logs for suspicious requests
7Test Advanced Payloads

If basic payloads are filtered, try encoding and obfuscation:

URL Encoding: %27%20OR%20%271%27%3D%271 Double URL Encoding: %2527%2520OR%2520%25271%2527%253D%25271 Unicode Encoding: \u0027 OR \u00271\u0027=\u00271 Case Variation: ' oR '1'='1
8Confirm Exploitability

Once injection is detected, test if it can be exploited:

  • Extract database version, table names, column names
  • Retrieve sensitive data (use test data, not production data)
  • Execute system commands (create a test file, not destructive actions)
  • Demonstrate privilege escalation or authentication bypass
⚠️ Ethical Testing: Always perform injection testing in authorized environments only. Never extract real user data or execute destructive commands. Use proof-of-concept demonstrations that show the vulnerability without causing harm.
9Document Findings

For each confirmed injection vulnerability, document:

  • Exact request (URL, method, headers, body)
  • Injection payload used
  • Server response showing vulnerability
  • Type of injection (SQL, NoSQL, Command, etc.)
  • Severity assessment (based on exploitability and impact)
  • Steps to reproduce
10Recommend Mitigations

Provide specific remediation guidance:

  • Use Parameterized Queries: Never concatenate user input into queries
  • Input Validation: Whitelist acceptable input patterns
  • Output Encoding: Encode data before using in queries or commands
  • Principle of Least Privilege: Database accounts should have minimal permissions
  • Web Application Firewall (WAF): Deploy WAF rules to detect and block injection attempts
// Example: Parameterized query (secure) const query = "SELECT * FROM users WHERE id = ?"; db.execute(query, [userId]);
// BAD: String concatenation (vulnerable) const query = "SELECT * FROM users WHERE id = " + userId; db.execute(query);
Essential Penetration Testing Tools
  • Burp Suite: Comprehensive web application security testing platform with proxy, scanner, and repeater
  • Postman: API development and testing tool useful for crafting and sending test requests
  • OWASP ZAP: Free, open-source web application security scanner
  • sqlmap: Automated SQL injection detection and exploitation tool
  • curl: Command-line tool for making HTTP requests with full control over headers and body
  • Wireshark: Network protocol analyzer for examining API traffic
  • JWT.io: Tool for decoding and analyzing JSON Web Tokens

Conclusion

The OWASP API Security Top 10 provides essential guidance for identifying and mitigating the most critical API vulnerabilities. By understanding these risks and implementing proper security controls, organizations can significantly reduce their attack surface and protect sensitive data.

Key takeaways:

Important Reminder: API security is an ongoing process, not a one-time implementation. Regular security assessments, code reviews, and staying updated with the latest threats are essential for maintaining a secure API ecosystem.