API Security Essentials - The OWASP Top 10

Why API Security Matters

APIs are now the primary target for attackers. Unlike traditional web attacks that target the UI, API attacks target the underlying logic and data directly. The OWASP API Security Top 10 is the industry standard awareness document for the most critical security risks to APIs.

Let’s look at a few of the most dangerous vulnerabilities and how to fix them.

1. Broken Object Level Authorization (BOLA)

The Problem: This is the #1 vulnerability for a reason. It happens when an API doesn’t verify that the user performing an action actually has permission to access the specific object (data record) they are requesting.

Example: User A changes the ID in the URL from /receipts/1001 to /receipts/1002 and sees User B’s receipt.

The Fix: Always validate that current_user.id == object.owner_id on every single access.

2. Broken Authentication

The Problem: Weak authentication mechanisms allow attackers to compromise authentication tokens or exploit implementation flaws. Example: Allowing weak passwords, not implementing rate limiting on login endpoints (brute force), or sending session tokens in the URL. The Fix: Use standard OAuth2/OIDC flows. Implement multi-factor authentication (MFA). Never roll your own crypto.

3. Broken Object Property Level Authorization

The Problem: Also known as “Mass Assignment”. This occurs when an API endpoint allows a client to update fields that they shouldn’t be able to (e.g., is_admin, account_balance).

Example: A user sends a JSON payload {"username": "me", "role": "admin"} to a profile update endpoint, and the backend blindly updates the database model.

The Fix: Use “Data Transfer Objects” (DTOs) or explicitly whitelist allowed fields for input.

4. Unrestricted Resource Consumption

The Problem: APIs that don’t limit the resources a client can request can be DoS’d easily.

Example: An endpoint that allows a user to request page_size=1000000, crashing the database.

The Fix: Implement strict rate limiting, pagination limits, and timeouts.

5. Broken Function Level Authorization

The Problem: Relying on the client (UI) to hide administrative functions instead of enforcing checks on the server.

Example: An admin endpoint DELETE /api/users/5 exists. The UI hides the button for normal users, but a hacker can just send the HTTP request directly.

The Fix: Check roles/permissions in the backend code or API Gateway for every administrative function.

6. Unrestricted Access to Sensitive Business Flows

The Problem: APIs that don’t properly protect sensitive operations or workflows allow attackers to bypass business logic constraints.

Examples

• A payment confirmation endpoint that doesn’t verify the transaction is in “pending” state, allowing refunds on already-completed transactions or duplicate payments.
• A password reset flow that doesn’t verify the user owns the email, allowing account takeover.

The Fix:

• Validate all state transitions and business rules on the server
• Implement strict verification for sensitive operations (email verification, 2FA, payment confirmation)
• Add transaction atomicity and idempotency keys to prevent duplicate operations
• Log all sensitive actions for audit trails

7. Server-Side Request Forgery (SSRF)

The Problem: An API accepts user-supplied URLs and fetches data from them without proper validation, allowing attackers to make requests to internal systems.

Examples

• An API endpoint that fetches images from URLs: GET /api/fetch-image?url=http://internal-database:5432. An attacker provides a URL pointing to internal infrastructure.
• Accessing cloud metadata services like http://169.254.169.254/latest/meta-data/ to retrieve AWS credentials.

The Fix:

• Never trust user-supplied URLs
• Maintain a whitelist of allowed domains
• Disable HTTP redirects or validate redirect destinations
• Block access to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.1, localhost)
• Use network-level controls (firewall rules) to restrict outbound connections
• Run API services with minimal IAM permissions

8. Lack of Protection from Automated Threats

The Problem: APIs lack mechanisms to detect and block automated attacks like credential stuffing, account enumeration, or scraping.

Examples

• An attacker rapidly tests thousands of username/password combinations against a login endpoint.
• An attacker queries /api/user-exists?email=... for thousands of emails to build a list of valid accounts.

The Fix:

• Implement rate limiting (per IP, per user, per API key)
• Add CAPTCHA challenges after failed login attempts
• Use bot detection tools (WAF, API Gateway filters)
• Implement account lockouts after multiple failed attempts
• Monitor for suspicious patterns (unusual request volumes, geographic anomalies)
• Use API keys and throttle anonymous requests more aggressively
• Implement exponential backoff for repeated failed requests

9. Improper Inventory Management

The Problem: APIs expose endpoints or versions that are no longer maintained, undocumented, or contain legacy functionality with security vulnerabilities.

Examples

• An old /api/v1/users/admin-list endpoint that bypasses authentication is still running in production alongside v2 and v3.
• Internal APIs intended only for backend services are exposed and accessible from the internet.

The Fix:

• Maintain comprehensive API inventory (versioning, ownership, last updated)
• Deprecate old versions with clear timelines
• Use API gateways to enforce versioning and sunsetting
• Disable or remove unused endpoints
• Separate internal and external APIs (use network segmentation)
• Document all endpoints including their purpose and access requirements
• Regularly scan for zombie endpoints using dependency tracking

10. Unsafe Consumption of APIs

The Problem: Applications that consume third-party APIs don’t validate, sanitize, or properly handle data returned from external sources, leading to injection attacks, data poisoning, or crashes.

Examples:

• Your API calls a weather service and renders the response in HTML without escaping, allowing XSS via the third-party API.
• Deserializing untrusted JSON/XML from an external API without validation, leading to object injection or code execution.
• Not implementing timeouts when calling external APIs, causing your service to hang and become unresponsive.

The Fix:

• Always validate and sanitize data received from external APIs
• Implement strict timeouts and circuit breakers for external API calls
• Use defensive coding practices (never blindly deserialize untrusted data)
• Escape all output appropriate for the context (HTML entities for web, parameterized queries for databases)
• Implement retry logic with exponential backoff and max retry limits
• Monitor external API dependencies and have fallbacks
• Use allowlists for acceptable response formats and values
• Never trust third-party API responses for security decisions

Implementation Best Practices

To effectively protect your APIs from these threats:

1. Security by Design: Build security into your API architecture from the start, not as an afterthought
2. Defense in Depth: Use multiple layers of protection (authentication, authorization, rate limiting, WAF, monitoring)
3. Principle of Least Privilege: Grant minimal necessary permissions to users, services, and API keys
4. Regular Audits: Conduct security reviews quarterly and after significant changes
5. Automated Testing: Integrate SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing) into your CI/CD pipeline
6. API Gateway: Use API gateways (Kong, AWS API Gateway, Azure API Management) to enforce security policies centrally
7. Monitoring & Alerting: Log and monitor all API access, authentication attempts, and suspicious patterns
8. Security Training: Ensure your team understands API-specific security risks

Conclusion

Security is not a feature; it’s a process. Regularly audit your APIs against the OWASP Top 10, use automated scanning tools, and most importantly, shift security left by designing your APIs with security in mind from day one. The OWASP Top 10 provides a foundation, but remember that new vulnerabilities emerge constantly. Stay informed, implement multiple layers of defense, and never assume your API is secure without continuous validation.