REST API Security: OWASP Top 10 Risks and How to Fix Them

If your API doesn't have explicit protections for the OWASP API Security Top 10, it is almost certainly vulnerable to at least one category on that list. The OWASP API Security Project—maintained by the Open Web Application Security Project, a globally recognized nonprofit authority on application security—documents the most critical and prevalent API security risks based on real-world breaches and security research. This is not theoretical: Broken Object Level Authorization alone has been responsible for high-profile data exposure incidents at major companies. Understanding each risk and applying systematic mitigations is how teams stop being reactive and start being resilient.

Image: Computer-security-incident-initial-process — Tanjstaffl (CC BY 2.5), via Wikimedia Commons

1. Broken Object Level Authorization (BOLA)

BOLA—also called Insecure Direct Object Reference (IDOR)—is consistently the most common and impactful API vulnerability. It occurs when an endpoint accepts a user-controlled identifier (an ID, UUID, or slug) and returns data for the object without verifying whether the requesting user is authorized to access it.

Example of the pattern:

GET /api/orders/48291
Authorization: Bearer <token for user A>

If user A can retrieve user B's order simply by changing the ID, that's BOLA. The fix requires enforcing ownership checks at the data layer, not just at the route level.

Fix: Always query with both the object ID and the authenticated user's identity. Use an ORM-level or repository-level filter: WHERE id = :id AND user_id = :auth_user_id. Never trust the ID alone.

2. Broken Authentication

Authentication vulnerabilities in APIs typically stem from one of four patterns: weak token generation, missing token expiration, missing rate limiting on auth endpoints, or improper handling of credentials. JWTs that never expire, API keys stored in URL parameters (where they appear in server logs), and password reset flows without rate limiting all fall here.

Fixes to apply:

• Enforce short-lived access tokens (15–60 minutes) with refresh token rotation
• Rate-limit login, password reset, and token refresh endpoints
• Require HTTPS for all API communication—never transmit tokens over plain HTTP
• Validate JWT signatures and check the exp, iss, and aud claims
• Never accept the alg: none JWT algorithm

3. Broken Object Property Level Authorization

This risk covers two related patterns: exposing sensitive object properties that should be private (excessive data exposure), and allowing clients to set object properties they should not control (mass assignment). A classic mass assignment scenario: a user sends {"role": "admin"} as part of a profile update, and the API binds it directly to the model.

Fix: Explicitly define which fields are readable and writable per endpoint, per role. Use allowlists (explicitly permitted fields), not blocklists. Return only the fields the client actually needs—never serialize entire ORM objects to JSON.

4. Unrestricted Resource Consumption

APIs without rate limiting and resource quotas are trivially exploitable for both denial-of-service and enumeration attacks. This includes missing limits on request rate, response size, query complexity (for GraphQL), pagination depth, and file upload size.

Implementation checklist:

• Apply per-user and per-IP rate limits on every endpoint, not just auth routes
• Set maximum page sizes for paginated endpoints (e.g., max_per_page=100)
• Enforce upload size limits at the gateway, not just in application code
• Add query complexity limits for GraphQL APIs
• Return 429 Too Many Requests with a Retry-After header

5. Broken Function Level Authorization

This is the administrative endpoint exposure problem. APIs often have privileged functions (delete all records, promote a user, access audit logs) that are only hidden by obscurity rather than enforced authorization. An attacker who discovers a DELETE /api/admin/users or POST /api/internal/batch-export endpoint can call it if authorization is missing or only checked by convention.

Fix: Treat every endpoint as public until proven otherwise. Enforce role-based or attribute-based access control at the middleware layer, not via naming conventions or optional documentation. Regularly audit your API surface for undocumented or forgotten endpoints.

6. Server-Side Request Forgery (SSRF)

SSRF vulnerabilities occur when an API accepts a URL from the client and fetches it server-side without validation. An attacker can use this to probe internal services (http://169.254.169.254/ for cloud metadata endpoints), access internal APIs, or exfiltrate data.

Fixes:

• Validate and sanitize all user-supplied URLs before any server-side fetch
• Allowlist permitted domains and protocols; deny private IP ranges (10.x.x.x, 172.16–31.x.x, 192.168.x.x, 127.x.x.x)
• Disable unnecessary URL-fetching features at the framework level
• Use a separate network segment or egress proxy for outbound requests

Image: Cybersecurity training (23523953708) — Germanna CC (CC BY 2.0), via Wikimedia Commons

7–10: Security Misconfiguration, Automated Threats, Inventory, and Unsafe API Consumption

The remaining four OWASP API Security risks are architectural and operational in nature:

• Security Misconfiguration: Exposed debug endpoints, overly permissive CORS (Access-Control-Allow-Origin: *), unnecessary HTTP methods enabled, and missing security headers (CSP, HSTS, X-Content-Type-Options) are extremely common. Automate configuration audits as part of your CI/CD pipeline.
• Lack of Protection from Automated Threats: APIs that power business logic (ticket booking, inventory reservation, OTP validation) need behavioral rate limiting beyond simple request counting. Distinguish between human and bot traffic; apply CAPTCHA or proof-of-work on sensitive flows.
• Improper Inventory Management: Retired API versions still accessible in production, shadow APIs created by development teams, and staging APIs reachable from the public internet all expand the attack surface. Maintain a complete, versioned API inventory and deprecate endpoints on a formal schedule.
• Unsafe Consumption of APIs: Your API trusts third-party APIs it calls downstream—but those APIs may return malicious data. Validate and sanitize data received from external APIs the same way you validate user input. A compromised third-party API should not be able to inject payloads into your system.

Frequently Asked Questions

Should we use API keys or JWTs for REST API authentication?

The answer depends on the use case. API keys are well-suited for machine-to-machine (M2M) or service-account access where long-lived credentials are acceptable and tightly controlled. JWTs are better for end-user sessions requiring short-lived, revocable access with embedded claims. Many production systems use both: JWTs for user-facing endpoints and API keys for server-to-server integrations, with separate secret rotation policies for each.

How often should we run API security assessments?

At minimum: run automated security scanning (DAST tools like OWASP ZAP or similar) on every significant release, and conduct a thorough manual penetration test annually or whenever major architectural changes occur. Continuous monitoring for anomalous traffic patterns—unusual ID patterns, repeated 403 responses, or abnormal request rates—should run in production at all times.

Is HTTPS alone enough to secure a REST API?

No. HTTPS encrypts data in transit and verifies server identity—it does not authenticate your users, enforce authorization rules, prevent injection attacks, or protect against BOLA. HTTPS is a necessary baseline, not a security strategy. Every item in the OWASP API Security Top 10 can be exploited over a perfectly valid HTTPS connection.

Bottom Line

API security is not a one-time audit—it is a continuous practice. We recommend beginning with the OWASP API Security Top 10 as your minimum security baseline, automating what can be automated (configuration scanning, rate limit enforcement, header checks), and establishing a regular cadence of manual security reviews for business-critical endpoints. The cost of a systematic security practice is small compared to the cost of a breach that could have been prevented by checking a user ID against the authenticated session.

Disclaimer: This article is for informational purposes only. Technology landscapes change rapidly; verify information with official sources before making technical decisions.