API Security
Top API Vulnerabilities: Most Common Security Flaws
The most common API vulnerabilities are: Broken Object Level Authorization (BOLA) — accessing other users' data by changing resource IDs; Broken Authentication — weak or missing authentication mechanisms; Excessive Data Exposure — APIs returning more data than needed; Lack of Rate Limiting — enabling brute-force and scraping attacks; Injection — SQL, NoSQL, and command injection through API parameters; Mass Assignment — attackers setting unauthorized fields; and Security Misconfiguration — default settings, verbose errors, unnecessary features.
Andreas Johansson · Chief Executive Officer
Senior IT management leader with 25 years of experience in Cloud, Security, and Datacenter infrastructure.
The API Vulnerability Landscape
API vulnerabilities differ from traditional web application vulnerabilities. While web apps are vulnerable to XSS and CSRF through browsers, APIs face direct programmatic attacks targeting business logic, authorization, and data access.
Broken Authentication
APIs with flawed authentication mechanisms allow attackers to impersonate legitimate users.
- Common flaws:
- No authentication on sensitive endpoints
- Weak token generation (predictable tokens, insufficient entropy)
- Tokens that don't expire or have excessively long lifetimes
- API keys transmitted in URLs (visible in logs, browser history, proxies)
- No brute-force protection on authentication endpoints
- Password reset flows that leak information or are bypassable
- Prevention:
- Use industry-standard authentication (OAuth 2.0, OpenID Connect)
- Implement short-lived tokens with refresh mechanisms
- Transmit credentials in headers, never URLs
- Rate limit authentication endpoints aggressively
- Implement MFA for sensitive operations
- Monitor for credential stuffing patterns
Excessive Data Exposure
APIs that return more data than the client needs create information disclosure risks.
- Example: A user profile API returns the full user object — including internal fields like password hashes, role assignments, internal IDs, and metadata — even though the client only displays name and email. The API relies on the client to filter sensitive fields.
- Why it happens: Developers create generic endpoints that return complete objects, expecting frontend code to display only relevant fields. But API responses are visible to anyone with an HTTP client — not just the frontend application.
- Prevention:
- Return only the fields the client needs for the specific use case
- Create specific response schemas for each endpoint
- Never rely on client-side filtering for security
- Review API responses for sensitive data leakage
- Use response serialization that explicitly defines output fields
Lack of Rate Limiting
APIs without rate limiting are vulnerable to volume-based attacks.
- Attack scenarios:
- Brute-force authentication — trying thousands of passwords per minute
- Credential stuffing — testing leaked credentials at scale
- Data scraping — extracting entire databases through API enumeration
- Denial of service — overwhelming API infrastructure with requests
- SMS/email bombing — abusing notification endpoints to harass users
- Prevention:
- Implement rate limiting per user, per API key, and per IP
- Use stricter limits on sensitive endpoints (login, password reset, payment)
- Implement progressive delays after failed authentication attempts
- Monitor for distributed attacks that bypass per-IP limits
- Use CAPTCHA or proof-of-work for public endpoints
Injection Attacks
API parameters that are incorporated into queries, commands, or expressions without sanitization enable injection attacks.
- Types:
- SQL injection — malicious SQL in parameters used in database queries
- NoSQL injection — manipulated JSON/BSON queries in MongoDB and similar databases
- Command injection — OS commands injected through parameters passed to system calls
- LDAP injection — malicious LDAP queries through authentication parameters
- Expression injection — manipulated expressions in template engines or rule engines
- Prevention:
- Use parameterized queries/prepared statements for all database access
- Validate and sanitize all input parameters
- Use ORMs and query builders that handle parameterization
- Never concatenate user input into queries or commands
- Apply least-privilege database permissions
Mass Assignment
APIs that automatically bind request parameters to internal object properties allow attackers to set unauthorized fields.
- Example: A user update endpoint accepts JSON and maps it directly to the user model. An attacker includes
"role": "admin"or"balance": 999999in their update request, and the API applies these fields. - Prevention:
- Explicitly define which fields are accepted for each endpoint
- Use allowlists (not blocklists) for input binding
- Create separate DTOs for input that only include modifiable fields
- Never expose internal model properties through API binding
Security Misconfiguration
Default configurations, unnecessary features, and verbose error messages create exploitable weaknesses.
- Common issues:
- Default credentials on API management platforms
- Verbose error messages exposing stack traces, database details, and internal paths
- CORS configured to allow all origins
- Unnecessary HTTP methods enabled (PUT, DELETE on read-only resources)
- Debug endpoints active in production
- API documentation (Swagger/OpenAPI) publicly accessible with sensitive endpoint details
- Prevention:
- Harden all API infrastructure configurations
- Return generic error messages to clients; log details internally
- Configure CORS with specific allowed origins
- Disable unnecessary HTTP methods per endpoint
- Remove debug endpoints from production
- Restrict access to API documentation
How SeqOps fits
SeqOps doesn't test APIs. It checks the cloud and server infrastructure your APIs run on, such as network exposure, access settings and unpatched software, so the platform underneath your APIs isn't the weak point.