REST APIs are the connective tissue of modern software—they power mobile apps, third-party integrations, microservices, and virtually every SaaS product in production today. They are also among the most consistently exploited attack surfaces in software development. The OWASP API Security Top 10 (2023 edition) catalogs the most prevalent and damaging vulnerability classes, and the patterns repeat across organizations of every size. This guide breaks down what matters most and how to address it.
Image: Authentication devices — Dicti0nary0 (CC BY-SA 3.0), via Wikimedia Commons
Why REST API Security Deserves Its Own Focus
Traditional web application security focused heavily on server-rendered HTML—XSS, CSRF, and session hijacking at the browser layer. REST APIs shift the trust boundary. The server now exposes raw data through structured endpoints, often authenticated with long-lived tokens rather than session cookies, frequently consumed by clients the developer never controls directly.
This architecture introduces vulnerability patterns that differ meaningfully from classic web security. Object-level authorization decisions happen at the endpoint, not the rendering layer. Data exposure often occurs through over-fetching rather than injection. Rate limiting and resource consumption become first-class security concerns rather than purely operational ones. Understanding this distinction shapes every decision that follows.
Broken Object Level Authorization (BOLA): The Most Common API Flaw
BOLA—also called Insecure Direct Object Reference (IDOR) at the API layer—tops the OWASP API Security list for the same reason it has appeared at or near the top of vulnerability rankings for over a decade: it is trivial to introduce and surprisingly easy to miss in code review.
The pattern is straightforward. An endpoint accepts an object identifier—a user ID, order ID, document ID—and returns the corresponding resource. If the server fails to verify that the authenticated caller is authorized to access that specific object, any user can enumerate other users' data by simply changing the ID in the request.
The fix requires an explicit authorization check on every object-level request, not just authentication. The questions are distinct: "Are you logged in?" (authentication) and "Are you allowed to access this specific record?" (authorization) must both be answered at every endpoint that accepts an identifier.
- Never rely on obscurity (UUIDs instead of sequential integers) as a substitute for access control
- Enforce ownership checks server-side:
WHERE id = ? AND owner_id = current_user_id - Test with two accounts—verify account A cannot read account B's resources through any endpoint
Broken Authentication and Token Management
Authentication vulnerabilities in REST APIs cluster around a few recurring patterns: weak token generation, improper token storage, missing token expiry, and flawed password reset flows.
JWTs (JSON Web Tokens) are the dominant authentication mechanism for REST APIs and introduce their own failure modes. Common implementation errors include accepting the none algorithm (which disables signature verification entirely), using symmetric signing secrets that are too short or predictable, and failing to validate the aud and iss claims—which allows tokens from one service to be used at another.
Stronger authentication practices for REST APIs:
- Always validate JWT signature, expiry, audience, and issuer before trusting claims
- Use short-lived access tokens (15–60 minutes) paired with refresh token rotation
- Store tokens in httpOnly cookies where possible rather than localStorage, which is accessible to any script on the page
- Implement token revocation for high-value operations (logout, credential change, privilege escalation)
- Rate-limit and lock authentication endpoints to prevent brute-force and credential stuffing
Excessive Data Exposure and Mass Assignment
REST APIs frequently expose more data than the consuming client needs, relying on the frontend to filter what gets displayed. This is a security anti-pattern, not just an efficiency issue. If a mobile app receives a full user object including internal flags, admin status fields, or hashed passwords—even if it only displays the username—any intercepted response leaks that data.
The correct approach is a dedicated response serialization layer that explicitly whitelists the fields returned per endpoint and per caller role. Never return raw ORM objects or database rows directly. Build response schemas that reflect exactly what each caller is authorized to see.
Mass assignment is the write-side equivalent. If your API accepts a JSON body and directly maps it to a model object, a caller can inject fields like is_admin: true or account_balance: 99999 if those fields exist on the model but were not intended to be user-settable. Always explicitly define which fields are writable through each endpoint.
Rate Limiting, Resource Consumption, and Attack Surface Hardening
Unrestricted resource consumption is the OWASP category that covers API endpoints with no limits on request frequency, payload size, or query complexity. This enables both denial-of-service scenarios and data scraping attacks at scale.
Every API endpoint needs its own rate limit calibrated to expected legitimate usage—authentication endpoints more aggressive than data retrieval endpoints, mutation operations more tightly constrained than reads. Rate limits should be applied at multiple levels: per IP, per user, and globally.
| Vulnerability Class | Core Fix | Detection Method |
|---|---|---|
| BOLA / IDOR | Per-request ownership check on every object-level endpoint | Cross-account testing, automated IDOR scanner |
| Broken Authentication | Short-lived tokens, full JWT validation, refresh rotation | JWT none-alg test, replay attack testing |
| Excessive Data Exposure | Explicit response schemas with field allowlisting | Response review, data flow audit |
| Mass Assignment | Explicit writable field list on every request handler | Send unexpected fields in POST/PUT and check if applied |
| Unrestricted Resource Consumption | Per-endpoint rate limits at IP, user, and global scope | Load test, high-frequency automated request probing |
| Security Misconfiguration | CORS lockdown, TLS enforcement, no debug endpoints in prod | Headers check, CORS probe, endpoint enumeration |
| Injection (SQLi, command) | Parameterized queries, input validation, ORM safety | SAST, fuzzing, manual payload testing |
Beyond rate limiting, attack surface hardening includes:
- Strict CORS policy: only allow origins you explicitly control; never echo the
Originheader back blindly - Remove debug and admin endpoints from production: /actuator, /debug, /health with full details
- Enforce TLS everywhere with HSTS; never accept plain HTTP for API traffic
- Validate content-type headers to prevent content-type confusion attacks
- Log authentication failures, authorization failures, and rate limit hits with enough context for forensic analysis
Injection Attacks and Input Validation
SQL injection remains the highest-severity vulnerability class despite decades of awareness, because it is introduced by one developer habit: concatenating user-supplied strings into query logic. The fix—parameterized queries and prepared statements—has been the correct answer for the same length of time. No ORM or database abstraction layer eliminates the need to understand this; many support raw query escape hatches that reintroduce the risk if used carelessly.
Beyond SQL injection, REST APIs are susceptible to command injection (when API parameters reach shell commands), NoSQL injection (when user input is interpreted as query operators in MongoDB-style systems), and Server-Side Request Forgery (SSRF), where an API fetches a URL supplied by the caller and the attacker points it at internal services.
Input validation should happen at the API boundary—not as a security substitute for parameterized queries, but in addition to it. Validate type, length, format, and acceptable range on every field before it reaches business logic or persistence layers.
Frequently Asked Questions
What is the single most impactful API security improvement a team can make?
Adding explicit object-level authorization checks (BOLA/IDOR prevention) to every endpoint that accepts a resource identifier. This class of vulnerability is extremely common, relatively easy to introduce during development, and can expose the entire dataset of every user. A single test—verifying that account A cannot read account B's resources—will catch it. Most teams do not run this test consistently.
Should I build API security into design or fix it later?
Design phase is dramatically cheaper. Authorization models, data exposure schemas, and rate limiting architectures are expensive to retrofit into a shipped API because they often require breaking interface changes. Authentication and authorization schemes should be decided before the first endpoint is written. Input validation and rate limiting are easier to add post-launch but should still be in scope for any initial release.
Are third-party API gateways sufficient for security?
Gateways handle some concerns well—rate limiting, TLS termination, basic authentication, and traffic logging—but they cannot replace application-level authorization. A gateway does not know that user 123 should not be allowed to read user 456's order history. That check must happen in your application code. Gateways and application security are complementary layers, not alternatives.
Bottom Line
The most exploited REST API vulnerabilities are not sophisticated zero-days—they are authorization gaps, token mismanagement, data over-exposure, and missing rate limits. The OWASP API Security Top 10 has documented these patterns clearly, and the fixes are well-understood. We recommend making object-level authorization testing a mandatory part of every API code review, adopting explicit response schemas with field allowlisting, and instrumenting every authentication failure for real-time alerting. Security in APIs is not a feature to add at the end—it is a design constraint that shapes how every endpoint is built from the start.
Sources & References:
OWASP API Security Top 10 — 2023 Edition. Open Web Application Security Project.
Disclaimer: This article is for informational purposes only. Technology landscapes change rapidly; verify information with official sources before making technical decisions.