Modern software systems are built on APIs. From powering single-page web applications and mobile apps to facilitating microservice-to-microservice communication, Application Programming Interfaces (APIs) handle the majority of internet traffic.
Because APIs expose business logic and sensitive underlying data directly to the web, they have become a primary target for cybercriminals. Protecting both REST and GraphQL interfaces requires moving beyond traditional web application firewalls (WAFs) to implement granular authentication, structural input validation, and strict execution controls.
The API Threat Landscape: REST vs. GraphQL
While REST and GraphQL share common security risks (such as broken authentication), GraphQL’s flexible design introduces unique attack vectors that do not exist in traditional REST architectures.
API Threat Vectors
[ REST API Vulnerabilities ] [ GraphQL API Vulnerabilities ]
├── Broken Object Level Auth (BOLA) ├── Query Depth & Cost Attacks (DoS)
├── Excessive Data Exposure ├── Introspection Abuse (Reconnaissance)
└── Mass Assignment └── Batching & Recursion Exploits
1. REST API Security Fundamentals
The OWASP API Security Top 10 highlights critical security flaws in RESTful endpoints:
Broken Object Level Authorization (BOLA / IDOR)
BOLA occurs when an API endpoint accepts an object identifier (e.g.,
/api/v1/users/1042/invoice) without verifying whether the requesting user actually owns that resource. Attackers simply iterate through ID numbers to exfiltrate private records.-
Defense: Validate user authorization at the database/data layer for every single request, rather than relying on frontend routing.
Excessive Data Exposure
REST endpoints often return complete data objects, relying on client-side code to filter what gets displayed. An attacker inspecting raw JSON responses can read hidden fields like password hashes, internal status flags, or PII.
-
Defense: Implement explicit Data Transfer Objects (DTOs) that sanitize responses, returning only the specific fields required by the UI.
Mass Assignment
Occurs when an API automatically maps incoming client JSON parameters directly to backend database models. An attacker can append extra parameters to a payload (e.g.,
"is_admin": true) to elevate permissions.-
Defense: Explicitly declare allowed fields (allowlisting) on input DTOs before passing data to ORMs or database operations.
2. GraphQL Security Essentials
GraphQL allows clients to request exact fields via a single HTTP endpoint (usually
/graphql). While flexible, this design creates unique operational risks:GraphQL Denial of Service (DoS) Attack Vector
Client Query ──► [ Deeply Nested / Recursive Query ] ──► Exhausts Server Memory / CPU
(e.g., author -> books -> author -> books)
Preventing Nested Query Abuse (DoS)
In GraphQL, a malicious actor can craft a deeply nested, recursive query that forces the server to execute thousands of nested database calls, crashing the application.
-
Defense: Set a maximum query depth limit and implement query cost analysis (assigning execution point values to fields) to block expensive requests before execution.
Disabling Introspection in Production
GraphQL introspection allows clients to query the schema itself to discover all available queries, mutations, types, and fields.
-
Defense: Disable introspection in production environments to prevent automated attackers from mapping your entire API schema.
Batching & Rate Limiting
GraphQL allows clients to batch multiple operations into a single HTTP request. Traditional IP-based rate limiters at the WAF level will miss this, seeing only one inbound request.
-
Defense: Apply rate limiting directly inside the GraphQL layer based on query complexity or operation counts rather than raw HTTP requests.
3. Universal API Security Best Practices
| Control Area | Security Mechanism | Implementation Action |
| Authentication | OAuth 2.0 / OpenID Connect (OIDC) | Use short-lived JWTs (JSON Web Tokens) with cryptographically signed signatures. |
| Transport Security | TLS 1.3 & mTLS | Enforce HTTPS everywhere; use Mutual TLS (mTLS) for zero-trust service-to-service calls. |
| Rate Limiting | Token Bucket Algorithm | Apply rate limits per IP, user ID, or API key using Redis or an API Gateway (e.g., Kong, AWS API Gateway). |
| Input Validation | Schema Validation | Validate all incoming JSON payloads against strict OpenAPI/Swagger specifications or JSON Schemas. |
| Cors Policy | Strict Access Control | Do not use wildcard Access-Control-Allow-Origin: * for authenticated enterprise API endpoints. |
Summary Checklist for API Security
-
[ ] Disable GraphQL Introspection in production.
-
[ ] Enforce Object-Level Authorization (BOLA checks) on every controller/resolver.
-
[ ] Implement Query Depth and Cost Analysis for GraphQL resolvers.
-
[ ] Strip sensitive fields using DTOs to prevent Excessive Data Exposure.
-
[ ] Deploy an API Gateway to handle rate limiting, TLS termination, and token verification centrally.