Most engineering teams spend considerable effort securing their web frontend and database layer, then ship APIs that are essentially open to abuse. According to analysis from multiple security research firms, APIs now account for the majority of application attack surface — not because they are inherently insecure, but because they are often built by developers who assume the API is "internal" or "only called by our app." Attackers do not share that assumption. If your application does anything useful, your API endpoints are being probed right now.
Why APIs Are a Distinct Security Problem
Traditional web security thinking evolved around HTML responses, cookies and browser-enforced same-origin policies. APIs break those assumptions. A REST or GraphQL endpoint does not care who is calling it — it responds to any well-formed HTTP request. That makes several attack patterns trivially easy:
- Credential stuffing: Automated bots fire millions of username/password combinations at your login endpoint until something works. No CAPTCHA required if your mobile app API skips it.
- Data scraping: A competitor (or data broker) walks your product catalogue, user listings or pricing data endpoint-by-endpoint, building a complete copy of your data asset.
- BOLA / IDOR: Broken Object Level Authorization — the attacker changes
user_id=1234touser_id=1235in an API call and reads someone else's data. The OWASP API Security Top 10 consistently ranks this as the most critical API flaw. - Excessive data exposure: The API returns the full user object (including private fields, internal flags, PII) when the frontend only displays three of those fields. Developers trusted the client to filter.
Authentication: Getting the Basics Right
Authentication failures are behind a disproportionate share of API breaches. The common mistakes are well-known, yet they recur constantly:
Token handling
JWTs are ubiquitous but routinely misconfigured. Verify the signature algorithm explicitly — never accept alg: none. Use short-lived access tokens (15–60 minutes) with refresh token rotation. Store tokens in memory or HttpOnly cookies, never in localStorage where XSS can reach them. If your API is consumed by a mobile app, implement certificate pinning to prevent token interception via proxy.
API key management
For machine-to-machine integrations, API keys are common. The problems: keys that never expire, keys with excessive permissions, keys embedded in client-side JavaScript (which is public), and no monitoring for anomalous key usage. Scope each key to the minimum permissions required. Rotate them on a defined schedule. Detect and alert on unusual call volumes or geographic patterns.
OAuth 2.0 implementation gaps
OAuth done correctly is solid. OAuth done carelessly introduces several exploitable gaps: missing state parameter validation (CSRF against the auth flow), over-broad scopes, missing PKCE for public clients, redirect URI mismatches accepted too loosely. Treat your OAuth implementation as a security-critical component and review it explicitly.
Rate Limiting and Throttling: More Nuanced Than You Think
A flat rate limit (100 requests/minute per IP) is a starting point, not a solution. Sophisticated scrapers rotate IPs and stay under per-IP thresholds while collectively hammering your service. Effective rate limiting requires layering:
| Layer | What it controls | Implementation approach |
|---|---|---|
| Per-IP limits | Blunt-force attacks from single sources | NGINX, API gateway, or WAF rules |
| Per-user/token limits | Authenticated abuse by compromised or malicious accounts | Application layer; Redis-backed sliding window counters |
| Per-endpoint limits | Expensive endpoints (search, export) abused disproportionately | Custom limits per route in your API gateway config |
| Behavioural limits | Distributed scraping below per-IP thresholds | Anomaly detection on access patterns; fingerprinting |
| Concurrency limits | Slow-rate resource exhaustion | Max concurrent connections per token/IP |
Implement rate limit response headers (X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After) so legitimate clients handle throttling gracefully. Return 429 with a meaningful message — not a 503 that looks like downtime.
Input Validation and Output Sanitisation
APIs receive structured input and the temptation is to trust it more than you should. Validate rigorously at the schema level before your business logic touches it:
- Type enforcement: If a field is an integer, reject strings. If an email, validate the format. Do not rely on your ORM to catch type violations safely.
- Size limits: Enforce maximum lengths on all string fields. An unbounded text field in a JSON body is an avenue for denial-of-service through large payloads.
- Allowlists over denylists: Define what valid input looks like and reject everything else, rather than trying to catch known-bad patterns.
- Nested object depth: GraphQL and JSON APIs accepting deeply nested queries can be weaponised for resource exhaustion. Limit query depth and complexity explicitly.
- Output scrubbing: Never return internal stack traces, database error messages or system paths in API error responses. Log them server-side; return a generic error ID to the client.
Securing Your APIs Against Scraping Specifically
Scraping sits in a grey zone — it does not always exploit a vulnerability, it just uses your API as intended but at volume and without authorisation. The defences are distinct from general security controls:
- Require authentication for all data endpoints. Guest access to paginated data is an invitation to scrape. Even a free account creates an attribution trail.
- Implement bot detection signals. Scraping bots typically have no browser fingerprint, no mouse movement, and exhibit mechanical request timing. Services like Cloudflare Bot Management or DataDome can help at the edge.
- Obfuscate resource identifiers. Sequential integer IDs (
/items/1001,/items/1002) make enumeration trivial. Use UUIDs or opaque tokens as resource identifiers. - Honeypot endpoints. Include fake endpoints that no legitimate client would call. Any traffic to those endpoints is definitionally automated, giving you a high-confidence signal for blocking.
- Terms of service and legal: Technical controls slow scrapers; legal agreements and enforcement stop the persistent ones. Make sure your ToS clearly prohibits automated data collection.
Monitoring and Incident Detection
You cannot secure what you cannot see. API security without monitoring is a one-way door: you defend at build time but have no visibility into what is happening at run time.
At minimum, log every API request with: timestamp, endpoint, HTTP method, authenticated user (or null), source IP, response code, and latency. Ship these logs to a centralised store and build alerts for:
- Spike in 401/403 responses from a single source (credential stuffing or recon)
- Unusually high volume of successful requests from a single authenticated token
- Sequential access patterns on resource identifiers (IDOR enumeration attempts)
- Requests to endpoints that should never be called from your known client applications
- Off-hours access to sensitive data endpoints
The engineering teams at Mexilet Technologies typically implement API monitoring as part of the initial build for client projects — not as an afterthought — because the cost of retrofitting observability into an undocumented API surface is consistently higher than building it in from the start.
The API Gateway as a Security Control Layer
If you are managing multiple microservices or have more than a handful of endpoints, an API gateway is not optional from a security standpoint. Services like Kong, AWS API Gateway, Apigee, or Traefik let you centralise authentication enforcement, rate limiting, request validation, SSL termination and logging — rather than reimplementing these controls inconsistently across every service.
The operational benefit: when you need to rotate credentials, change rate limits, or block an IP, you do it in one place. The security benefit: you cannot accidentally forget to add auth middleware to a new service when auth is enforced at the gateway layer.
Frequently Asked Questions
What is BOLA and why does it keep appearing in breach reports?
BOLA stands for Broken Object Level Authorization. It happens when an API accepts a resource identifier from the client and retrieves that resource without checking whether the authenticated user is actually allowed to access it. It is prevalent because it is invisible to automated scanners — the endpoint returns 200 and the data looks valid. Only a human tester, or a behavioural anomaly alert, will catch it. Every API that uses user-controlled resource IDs needs explicit ownership checks on every request, not just at login.
Is HTTPS enough to protect API data in transit?
HTTPS encrypts the connection, which prevents passive eavesdropping on the wire. It does not protect against compromised clients, man-in-the-middle attacks via rogue certificates, or any attack that occurs after the data reaches your server. For mobile apps handling sensitive data, add certificate pinning. For service-to-service communication inside your infrastructure, mutual TLS (mTLS) provides stronger guarantees than one-way TLS.
Should we use an API security scanning tool in CI/CD?
Yes, but with calibrated expectations. Tools like 42Crunch, Spectral, or OWASP ZAP in API mode can catch structural issues (missing auth declarations, inconsistent schemas, dangerous patterns) before code ships. They will not catch business-logic flaws or BOLA. Treat automated scanning as your first filter — run it on every pull request — and supplement with periodic manual review or penetration testing for endpoints that handle sensitive data.
How do we handle third-party API integrations securely?
Third-party integrations are a frequently overlooked part of your attack surface. Store third-party API keys in a secrets manager (AWS Secrets Manager, HashiCorp Vault, Google Secret Manager) — never in environment variables in your codebase or CI/CD configuration files. Audit what permissions each third-party key holds and reduce them to the minimum. Monitor for unexpected calls from your application to third-party services — a compromised key used by an attacker will show up in your outbound request logs.
Mexilet Technologies supports teams on exactly this kind of work through our cybersecurity services and secure cloud & DevOps.
Hardening APIs is genuinely iterative work — there is no single control that closes all the gaps described above. If you want to de-risk the process, a small scoped engagement is often the right first step: a four-to-six week security sprint where the team reviews your current API design, implements the highest-priority controls, and sets up monitoring before moving on to more complex hardening. Talk to the Mexilet security engineering team about what a focused API security pilot would look like for your specific stack.