How to Protect APIs from Attacks: Developer Guide

How to Protect APIs from Attacks: Developer Guide

Modern application architecture operates entirely on Application Programming Interfaces (APIs). Whether it is a React Single Page Application (SPA), an iOS mobile app, or a Server-to-Server microservice, data flows through your API. Due to their foundational importance, APIs have become the primary target for malicious actors.

An unsecured API is equivalent to leaving the master key to your database hanging on the front door. Below, we break down actionable practices for developers to harden their endpoints against modern threats.

How to Protect APIs from Attacks: Quick Answer

API security requires four core controls applied together: enforce object-level authorization checks so users can only access their own data, authenticate with tightly scoped tokens or httpOnly session cookies, validate and whitelist all incoming JSON fields to prevent mass assignment, and rate-limit endpoints to block brute-force and enumeration attacks. Aligning with the OWASP API Security Top 10 provides the definitive framework for this defence-in-depth approach.

The Broken Object Level Authorization (BOLA) Nightmare

By far, the most critical vulnerability facing APIs today is Broken Object Level Authorization (BOLA). It occurs when an application correctly authenticates a user but fails to verify if that specific user has permission to access the requested data object.

Consider a banking application where a user requests their account details via the endpoint /api/accounts/1024.

BOLA occurs if the backend simply takes the 1024 from the URL, queries the database, and returns the data without checking if the currently logged-in user actually owns account 1024. If malicious users modify the URL to /api/accounts/1025, they might instantly access someone else's financial data.

Preventing BOLA in Code

You must always link the requested resource to the universally unique identifier (UUID) derived securely from your server-side session or JWT token, rather than blindly trusting the client-provided parameter.

By mandating that the ownerId perfectly matches to the req.user.id, the attacker cannot enumerate and steal sibling accounts via parameter manipulation.

JWT vs Stateful Sessions

Authentication is the prerequisite to authorization, establishing identity. When building an API, developers frequently debate whether to use JSON Web Tokens (JWT) or traditional State-backed Sessions.

Unless you are strictly communicating server-to-server, modern security consensus often leans toward using stateful, tightly scoped session IDs stored in httpOnly secure cookies for web browsers to prevent catastrophic token theft via Cross-Site Scripting.

Mass Assignment: The Hidden Injection

Modern frameworks like Spring Boot, Laravel, or Express allow developers to bind HTTP request payloads directly to database objects for rapid development. This convenience introduces a severe vulnerability known as Mass Assignment.

If you update a user model by directly pushing req.body into your ORM:

An attacker can easily append administrative flags or change their role by adding unexpected fields to the JSON payload.

Defending Against Mass Assignment

You must explicitly define the schemas detailing exactly what fields are permitted to be updated. This is often called Data Transfer Object (DTO) mapping or whitelisting.

Designing Secure API Paradigms

Securing an API requires shifting away from trusting input. By enforcing rigorous Object Level Authorization checks on every single route, explicitly validating incoming JSON structured payloads, and ensuring authentication tokens are handled securely, you eliminate the mechanisms that cause vast data leaks.

In our next web security installment, we will pivot to infrastructure, detailing exactly how to store the critical secrets, database passwords, and API keys that power these applications without inadvertently leaking them to GitHub.

Rate Limiting and Throttling

Without rate limiting, an attacker can enumerate all user IDs in your database by firing thousands of requests per minute. Apply per-IP and per-user rate limits to every sensitive endpoint.

For high-scale APIs, consider moving rate limiting to your API gateway (Kong, AWS API Gateway) so it applies before requests reach your application servers.

Sensitive Data Exposure Prevention

Many APIs inadvertently expose internal data by returning entire database records to the client. Always serialize only the fields the client explicitly needs.

This is also why response schemas and explicit serialization libraries (e.g., class-transformer in TypeScript) are recommended over raw ORM objects.

API Versioning and Deprecation

Unsupported legacy API versions accumulate unpatched vulnerabilities over time. Adopt a versioning strategy from day one:

• URI versioning: /api/v1/tasks, /api/v2/tasks
• Header versioning: Accept: application/vnd.myapp.v2+json

Communicate deprecation timelines to API consumers with a minimum 6-month notice, and monitor which clients are still calling sunset endpoints before removing them.

Logging and Monitoring API Activity

Without logs, you cannot detect an attack in progress. At a minimum, record the following for every API request:

• Authenticated user ID (not the token itself)
• Endpoint path and HTTP method
• Response status code
• Request duration
• Client IP address

Forward these logs to a centralized system (Datadog, AWS CloudWatch, ELK Stack) and set alerts for spikes in 401/403 responses — a common indicator of enumeration attacks.

Related Security Reading

• How to secure web applications — complementary guide covering OWASP Top 10, HTTPS, and CSP headers.
• Basic threat detection for developers — identifying attackers through log analysis and anomaly detection.
• Go security best practices — backend-specific controls for Go APIs including gosec and parameterized queries.
• How to avoid online phishing attacks — the social engineering layer that bypasses technical API controls.

For the authoritative API security specification, the OWASP API Security Project publishes the full Top 10 list with detailed prevention guidance for each category.

Common API Security Mistakes

1. Returning verbose error messages to clients Error responses that include stack traces, database error messages, or internal file paths leak implementation details to attackers. Return generic messages to clients ({"error": "Internal server error"}) and log full details server-side. The OWASP API Security Top 10 lists improper error handling as a leading API risk.

2. Not rate limiting authentication endpoints Login, password reset, and OTP endpoints without rate limiting are vulnerable to brute-force attacks. Implement per-IP and per-account rate limits using a sliding window counter (Redis-backed or in-memory). Return 429 Too Many Requests with a Retry-After header when limits are exceeded. Many API gateways (AWS API Gateway, Kong, Nginx) have built-in rate limiting modules.

3. Storing API keys in source code Hardcoded API keys and secrets in source code are routinely exposed in public GitHub repositories. Use environment variables (os.environ.get("API_KEY")) or a secrets manager (AWS Secrets Manager, HashiCorp Vault) to inject credentials at runtime. Tools like GitLeaks can scan repositories for accidentally committed secrets before they go public.

4. Missing CORS configuration An API with no CORS policy either rejects legitimate browser requests or, when set to Access-Control-Allow-Origin: *, allows any origin to make credentialed requests. Define an explicit allowlist of trusted origins and reject requests from others. The MDN CORS documentation is the authoritative reference.

5. Not validating and sanitising all input Every field in a request body, query string, header, and path parameter is potential attacker-controlled input. Validate type, length, and format before processing. For SQL interactions, always use parameterised queries — never string-interpolated SQL. For HTML output, escape user-supplied data to prevent XSS. See the OWASP Input Validation Cheat Sheet.

Frequently Asked Questions

What is the OWASP API Security Top 10? The OWASP API Security Top 10 is a regularly updated list of the most critical API security risks, maintained by the Open Web Application Security Project. The 2023 edition covers: Broken Object Level Authorization (BOLA), Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery, Security Misconfiguration, Improper Inventory Management, and Unsafe Consumption of APIs. It is the industry-standard reference for API security requirements.

How should I secure API keys distributed to client applications? API keys embedded in mobile apps or browser JavaScript are inherently public — a determined attacker can extract them. Mitigate this with: short-lived tokens issued per session rather than long-lived static keys; domain or bundle ID restrictions on the key's usage; rate limiting per key; monitoring for anomalous usage patterns. For high-value operations, route requests through your own backend rather than calling third-party APIs directly from the client. The Google Cloud API key best practices document many of these patterns.

What is the difference between authentication and authorisation in API security? Authentication verifies identity: "who are you?" (API key, JWT, OAuth token). Authorisation determines permissions: "what are you allowed to do?" (can this user read this resource? write to it? delete it?). Most API security vulnerabilities are authorisation failures — the API correctly identifies the user but fails to check whether that specific user is permitted to access the requested resource. Broken Object Level Authorization (BOLA/IDOR) is the most common API vulnerability in the wild. See the OWASP BOLA explanation for examples.

Continue Learning

If you are new to security concepts and want to understand the attacker perspective before applying defences, read the Introduction to Ethical Hacking — it explains reconnaissance, enumeration, and responsible disclosure in practical terms.