API Security Types of APIs REST SOAP GraphQL and gRPC
Not all APIs are built the same way. Different types of APIs use different communication styles, data formats, and rules. Each type brings its own set of security strengths and weaknesses. Understanding these differences lets you apply the right security controls to each one.
This topic covers the four most common API types used in production systems: REST, SOAP, GraphQL, and gRPC. You will see how each one works, where each one is used, and what specific security risks each one introduces.
REST APIs
REST stands for Representational State Transfer. It is the most popular API style in use today. Almost every public API you interact with as a developer — Google Maps, Twitter, Stripe, GitHub — is a REST API.
How REST Works
REST uses standard HTTP methods to perform actions on resources. A resource is any piece of data the API manages — a user, an order, a product, a message.
REST Resource Model for a Banking App: Resource: Account GET /api/accounts → List all accounts (for the logged-in user) GET /api/accounts/501 → Get details of account 501 POST /api/accounts → Open a new account PUT /api/accounts/501 → Update all details of account 501 DELETE /api/accounts/501 → Close account 501 Resource: Transaction GET /api/accounts/501/transactions → List transactions for account 501 GET /api/accounts/501/transactions/99 → Get transaction number 99 POST /api/accounts/501/transactions → Make a new transaction
The URL structure represents a hierarchy. Account 501 owns its transactions. This model is intuitive and easy to understand — which is one reason REST became so dominant.
Data Format in REST
REST APIs almost always use JSON (JavaScript Object Notation). JSON is lightweight, human-readable, and easy for programs to parse.
JSON Response from GET /api/accounts/501:
{
"id": 501,
"holder": "Ananya Kapoor",
"balance": 18500.00,
"currency": "INR",
"status": "active",
"opened_on": "2022-03-10"
}
REST Security Considerations
REST is flexible by design — and flexibility creates room for mistakes.
The most critical REST-specific risk is insecure direct object references. Because REST URLs contain resource IDs directly — like /api/accounts/501 — an attacker can simply change the number and try to access other users' accounts. The server must verify that the requesting user owns or is authorized to access that specific resource. Many implementations forget this check.
REST APIs also have no built-in schema enforcement. The server accepts whatever data the client sends. Without explicit input validation, attackers send unexpected data types, extremely large payloads, or special characters designed to break the server.
SOAP APIs
SOAP stands for Simple Object Access Protocol. It is an older, more structured API standard used heavily in enterprise systems, banking, healthcare, and government applications. While REST dominates new development, SOAP is deeply embedded in legacy systems and will exist for many years.
How SOAP Works
SOAP always uses XML as its data format. Every SOAP message follows a rigid envelope structure.
SOAP Message Envelope Structure: ┌─────────────────────────────────────┐ │ SOAP Envelope │ │ ┌──────────────────────────────┐ │ │ │ Header (optional) │ │ │ │ - Authentication info │ │ │ │ - Transaction IDs │ │ │ └──────────────────────────────┘ │ │ ┌──────────────────────────────┐ │ │ │ Body (required) │ │ │ │ - The actual request data │ │ │ │ - Or the fault/error info │ │ │ └──────────────────────────────┘ │ └─────────────────────────────────────┘
A real SOAP request to check a bank balance looks like this:
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<auth:Token>abc123securetokenxyz</auth:Token>
</soap:Header>
<soap:Body>
<bank:GetBalance>
<bank:AccountNumber>501</bank:AccountNumber>
</bank:GetBalance>
</soap:Body>
</soap:Envelope>
WSDL: The SOAP Contract
SOAP services publish a WSDL (Web Services Description Language) file. This XML document describes every operation the service supports, what parameters each operation accepts, and what it returns. WSDL is like a detailed instruction manual for the API.
Security risk: A public WSDL file gives attackers a complete map of all available operations. Attackers use this to identify functions that should not be publicly accessible, or to craft malformed inputs for specific parameters.
SOAP Security Considerations
SOAP's biggest unique vulnerability is XML External Entity (XXE) attacks. Because SOAP uses XML, an attacker can embed special XML directives in a request that instruct the server to load local files or make network requests.
XXE Attack Example in SOAP Body:
<soap:Body>
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<bank:GetBalance>
<bank:AccountNumber>&xxe;</bank:AccountNumber>
</bank:GetBalance>
</soap:Body>
If the XML parser is not configured to disable external entities, it reads the local /etc/passwd file and returns its contents in the response. XXE attacks are a dedicated topic later in this course.
GraphQL APIs
GraphQL is a newer API query language developed by Facebook (now Meta) and released publicly in 2015. It solves a specific problem: with REST, clients often have to make multiple requests to get all the data they need, or receive far more data than they need. GraphQL lets the client ask for exactly the data it wants, in a single request.
How GraphQL Works
Instead of many endpoints like REST, GraphQL has a single endpoint — usually /graphql. Clients send queries describing exactly what data they want.
REST vs GraphQL for Loading a User Profile Page:
WITH REST (multiple requests):
GET /api/users/101 → Get user basic info
GET /api/users/101/posts → Get user's posts
GET /api/users/101/friends → Get user's friends
(3 separate HTTP requests)
WITH GraphQL (single request to /graphql):
query {
user(id: 101) {
name
email
posts {
title
created_at
}
friends {
name
}
}
}
(1 request, exactly the fields needed)
The server returns exactly the fields asked for — nothing more, nothing less.
GraphQL Mutations and Subscriptions
GraphQL has three operation types. Queries read data. Mutations change data. Subscriptions listen for real-time updates.
GraphQL Mutation (creating a new post):
mutation {
createPost(
title: "My New Article",
content: "Article text here...",
author_id: 101
) {
id
title
created_at
}
}
GraphQL Security Considerations
GraphQL introduces security challenges that REST does not have.
The most dangerous is introspection. GraphQL servers support a built-in introspection system that lets clients ask: "What types and queries does this API support?" This is useful for developers building applications. For attackers, it is a complete blueprint of the entire API.
Introspection Query:
{ __schema { types { name fields { name } } } }
This returns every type, every field, and every operation available.
On a production server with sensitive internal types, this is a data leak.
Another risk is deeply nested queries. Because GraphQL lets clients specify relationships, an attacker can craft a query that goes many levels deep, forcing the server to join enormous amounts of data from the database.
Malicious Deeply Nested GraphQL Query:
{
users {
friends {
friends {
friends {
friends {
posts { comments { author { friends { ... } } } }
}
}
}
}
}
}
A query like this can bring a server to its knees by consuming enormous database and memory resources. This is a GraphQL-specific denial-of-service vector. Defenses include query depth limits, query complexity limits, and disabling introspection in production.
Authorization is also harder in GraphQL. In REST, you can protect a specific URL: "Only admins can access /api/admin/users". In GraphQL, everything goes to one endpoint. You must implement field-level authorization — checking whether the requesting user is allowed to see each specific field they asked for. Forgetting to check authorization on even one field causes data exposure.
gRPC APIs
gRPC (Google Remote Procedure Call) is an API framework built for high-performance communication between services. It is used primarily in microservices architectures — systems where many small services talk to each other inside a data center. gRPC is not typically used for public APIs that browser-based applications call directly.
How gRPC Works
gRPC uses Protocol Buffers (Protobuf) as its data format instead of JSON or XML. Protocol Buffers encode data in a compact binary format that is much smaller and faster to process than text-based formats.
Comparison: Same Data in Different Formats
JSON (text):
{"user_id": 101, "name": "Priya", "balance": 18500}
→ 49 bytes, human-readable
XML (text):
<user><id>101</id><name>Priya</name><balance>18500</balance></user>
→ 71 bytes, human-readable
Protobuf (binary):
Binary encoded bytes (approximately 20-25 bytes)
→ Smallest size, not human-readable without schema
In a system that makes millions of internal service calls per second, the difference between 49 bytes and 25 bytes multiplied across millions of requests saves enormous bandwidth and latency.
gRPC Service Definition
gRPC services are defined using a .proto file that specifies available methods and message types. This acts like a contract between services.
Example .proto definition for a payment service:
service PaymentService {
rpc ProcessPayment (PaymentRequest) returns (PaymentResponse);
rpc GetTransactionStatus (TransactionRequest) returns (TransactionResponse);
}
message PaymentRequest {
string account_from = 1;
string account_to = 2;
double amount = 3;
string currency = 4;
}
message PaymentResponse {
string transaction_id = 1;
string status = 2;
}
gRPC Security Considerations
gRPC uses HTTP/2 as its transport protocol. TLS is strongly recommended and typically enforced in production. Because gRPC is used for internal service-to-service communication, the threat model is slightly different.
The primary concern in gRPC is authentication between services. In a microservices system, Service A calls Service B. How does Service B know the request actually came from Service A and not from an attacker who accessed the internal network? Mutual TLS (mTLS) is the standard solution — both the client service and the server service present certificates to each other.
mTLS in gRPC: Without mTLS: Service A → calls → Service B Attacker also → calls → Service B (no way to tell them apart) With mTLS: Service A presents its certificate → Service B verifies it Attacker has no valid certificate → Service B rejects the connection
Another gRPC-specific concern is that Protobuf's binary format hides the data from standard security tools. Firewalls, WAFs (Web Application Firewalls), and logging systems that work at the HTTP layer cannot inspect binary Protobuf content without special decoders. This makes anomaly detection harder.
Comparing API Types Side by Side
Feature Comparison:
REST SOAP GraphQL gRPC
Data Format JSON XML JSON Binary (Protobuf)
Transport HTTP HTTP/HTTPS HTTP HTTP/2
Schema Optional Required Required Required (.proto)
(OpenAPI) (WSDL) (Schema)
Flexibility High Low Very High Medium
Performance Good Lower Good Excellent
Primary Use Public APIs Enterprise Web/Mobile Microservices
Web/Mobile Legacy Apps Internal
Security Risks:
REST: IDOR/BOLA, missing validation, no schema
SOAP: XXE attacks, WSDL exposure, bloated parsers
GraphQL: Introspection, deep queries, field-level auth
gRPC: mTLS complexity, binary inspection gaps
Choosing the Right Security Approach per API Type
Each API type requires tailored security thinking. Generic security checklists do not account for type-specific risks.
For REST APIs
Always verify that the authenticated user owns the resource they are requesting, not just that the resource exists. Use OpenAPI/Swagger specifications to define and enforce what fields are accepted in requests and returned in responses. Apply rate limiting on every endpoint, not just the authentication endpoints.
For SOAP APIs
Disable XML external entity processing in your XML parser. Never expose WSDL files publicly if the service is not meant for public use. Use WS-Security extensions for message-level encryption if the SOAP service carries sensitive data through intermediaries.
For GraphQL APIs
Disable introspection in production environments. Implement query depth limits (typically no more than 5-7 levels deep) and query complexity scores. Apply authorization checks at the resolver level — for every field, not just at the operation level. Log all GraphQL queries to detect abuse patterns.
For gRPC APIs
Use mutual TLS between all services. Implement service accounts and verify service identity at the gRPC authentication layer. Configure logging and monitoring tools that understand Protobuf format so that anomalous traffic can be detected. Restrict which services can call which gRPC endpoints using network-level and application-level policies.
API Documentation and Security
Every API type has associated documentation standards. REST uses OpenAPI (formerly Swagger). SOAP uses WSDL. GraphQL uses its schema definition language. gRPC uses proto files.
This documentation is essential for developers — it describes every endpoint, parameter, and expected response. But it also helps attackers map attack surfaces quickly.
The security principle is simple: restrict access to API documentation based on who needs it. Internal-only APIs should have documentation accessible only from the internal network. Production REST APIs should not have auto-generated Swagger UIs enabled unless you explicitly want them public. GraphQL introspection should be disabled in production.
Key Points
- REST is the most common API style. It uses HTTP methods and JSON. Its main security risk is insecure direct object references where resource IDs in URLs can be manipulated.
- SOAP is an enterprise standard using XML. Its main unique risk is XXE attacks through XML parsing, and exposure of the WSDL contract file.
- GraphQL uses a single endpoint and lets clients specify exactly what data they want. Introspection exposure and deeply nested queries are its primary unique threats.
- gRPC is used for fast internal service communication using binary Protobuf data. Mutual TLS between services and binary-aware monitoring are its main security requirements.
- No single security approach covers all API types. Each requires specific controls tailored to its communication model and data format.