--- title: "API Gateway Security and Compliance: A Buyer's Checklist" description: "Evaluate API gateway security features — authentication, encryption, DDoS protection, audit logging, and compliance certifications. A practical checklist for security-conscious teams." canonicalUrl: "https://zuplo.com/learning-center/api-gateway-security-compliance" pageType: "learning-center" authors: "nate" tags: "API Security" image: "https://zuplo.com/og?text=API%20Gateway%20Security%20and%20Compliance%3A%20A%20Buyer's%20Checklist" --- Your API gateway is the front door to your infrastructure. Every request to your backend services passes through it. Every authentication decision, every rate limit check, every payload validation happens there. If your gateway is not secure, nothing behind it matters -- attackers will walk right through. Yet when teams evaluate API gateways, security often takes a back seat to performance benchmarks and feature checklists. That is a mistake. A breach through a misconfigured or under-secured gateway can expose customer data, violate compliance obligations, and erode trust in ways that take years to rebuild. This guide walks through the security capabilities you should demand from any API gateway, explains why each one matters, and provides a concrete checklist you can use during vendor evaluation. Whether you are building for a startup handling its first API integration or an enterprise navigating SOC 2 and HIPAA requirements, this is what you need to know. ## Authentication and Authorization Authentication and authorization are the most fundamental security controls your gateway provides. Without them, every endpoint is effectively public. ### What to Evaluate **Built-in authentication methods.** Your gateway should support multiple authentication mechanisms out of the box. At minimum, look for: - **API key authentication** -- The most common method for server-to-server communication. The gateway should manage key issuance, rotation, and revocation without requiring custom code. - **JWT and OAuth 2.0 validation** -- For token-based authentication, the gateway needs to validate JWTs against issuer keys, check expiration and claims, and support standard OAuth 2.0 flows. - **Mutual TLS (mTLS)** -- For high-security environments, both client and server should present certificates. This is increasingly required in financial services and healthcare APIs. **Custom auth policy support.** No two organizations have exactly the same authentication requirements. The gateway should let you write custom authentication logic -- checking tokens against an external database, combining multiple auth methods, or implementing proprietary schemes -- without forking the gateway itself. **Multi-IdP integration.** Enterprise customers often need to authenticate against multiple identity providers simultaneously. Your gateway should support integration with providers like Auth0, Okta, Azure AD, and others, and it should handle the complexity of routing authentication to the correct provider based on request context. **Role-based access control (RBAC).** Beyond verifying identity, the gateway needs to enforce what authenticated users can do. RBAC policies should be configurable per route, per method, and per resource, so that a read-only API consumer cannot execute write operations. Zuplo provides [built-in policies for API key authentication](https://zuplo.com/docs/articles/api-key-authentication), JWT validation, and custom auth handlers that can be composed together. API keys are managed through a dedicated key management system that supports metadata, expiration, and consumer-level tracking. ## Encryption and Transport Security Data in transit between clients and your gateway -- and between the gateway and your backend -- must be encrypted. This is non-negotiable. ### What to Check **TLS 1.3 support.** TLS 1.3 is the current standard, offering faster handshakes and stronger cipher suites than TLS 1.2. Your gateway should support it by default and ideally deprecate older protocol versions. **Automatic certificate management.** Manually managing SSL certificates is error-prone and a common source of outages. The gateway should handle certificate provisioning, renewal, and installation automatically, ideally through integration with services like Let's Encrypt or your cloud provider's certificate manager. **HTTPS enforcement.** Every request should be served over HTTPS. The gateway should either redirect HTTP to HTTPS automatically or reject plaintext requests entirely. There should be no configuration that allows unencrypted traffic to reach your backend. **End-to-end encryption.** Traffic between the gateway and your origin servers should also be encrypted. Some gateways terminate TLS at the edge and then forward requests to backends over plaintext -- this creates a window of exposure that sophisticated attackers can exploit. **Certificate pinning options.** For APIs handling sensitive data, certificate pinning adds an extra layer by ensuring the client only trusts specific certificates. While not required for every use case, the option should be available. ## DDoS and Abuse Protection APIs are prime targets for denial-of-service attacks. A single endpoint that triggers an expensive database query can bring down your entire service if an attacker floods it with requests. ### Key Capabilities **Rate limiting.** This is the first line of defense. Your gateway should support rate limiting at multiple levels: - Per-consumer limits based on API key or token identity - Per-IP limits to prevent unauthenticated abuse - Per-endpoint limits to protect expensive operations - Global limits to safeguard overall system capacity Rate limits should be configurable with different windows (per second, per minute, per hour) and should return proper `429 Too Many Requests` responses with `Retry-After` headers. **IP blocking and allowlisting.** The gateway should support blocking known malicious IPs and restricting access to known client IPs. This should be manageable through both configuration and API, so it can be automated in response to detected threats. **Bot detection.** Sophisticated abuse often comes from bots that mimic legitimate traffic patterns. Look for gateways that integrate with bot detection services or provide heuristics for identifying automated traffic. **Request size limits.** Large payloads can be used as a denial-of-service vector. The gateway should enforce maximum request body sizes and reject oversized payloads before they consume backend resources. **Geographic restrictions.** If your API only serves customers in certain regions, the gateway should be able to block or restrict traffic from other geographies. This reduces your attack surface and can help with data residency compliance. **Edge deployment advantage.** Gateways deployed at the edge -- close to users on a global CDN -- can absorb attacks before they reach your infrastructure. Instead of funneling all traffic through a single point, edge-deployed gateways distribute the load across hundreds of points of presence, making volumetric attacks far less effective. ## Input Validation Validation at the gateway is your first opportunity to reject malformed or malicious requests before they reach your application code. This is a critical defense layer. ### Why It Matters Many API vulnerabilities -- injection attacks, schema violations, data exfiltration through overly broad queries -- can be prevented by validating requests at the gateway. If a request does not conform to your API contract, it should never reach your backend. **OpenAPI schema validation.** If you define your API with an [OpenAPI specification](https://zuplo.com/docs/articles/open-api), the gateway should validate every incoming request against that schema. This means checking path parameters, query strings, headers, and request bodies against the types, formats, and constraints you have defined. **JSON schema validation.** For request bodies, deep JSON schema validation catches structural issues like missing required fields, incorrect types, values outside allowed ranges, and unexpected additional properties. **Header validation.** Required headers should be checked for presence and format. Content-Type enforcement prevents clients from sending unexpected payload formats. **Query parameter validation.** Unexpected or malformed query parameters should be rejected, especially for endpoints that use parameters in database queries. Zuplo's [JSON validation policy](https://zuplo.com/docs/policies/request-validation-inbound) validates requests against your OpenAPI schema automatically. Any request that does not match the schema is rejected with a detailed error response before it reaches your backend. ## Audit Logging and Monitoring Security without visibility is security theater. You need to know who accessed what, when, and what happened as a result. ### Requirements **Request and response logging.** Every API call should be logged with enough detail to reconstruct what happened: timestamp, client identity, requested resource, response code, and latency. For sensitive operations, response bodies may also need to be captured. **User attribution.** Logs must tie requests to specific consumers. Anonymous traffic should still be attributable by IP, and authenticated traffic should carry the consumer identity through the entire log chain. This is essential for investigating incidents and for compliance audits. **Real-time alerting.** When something goes wrong -- a spike in 5xx errors, an unusual volume of authentication failures, a sudden increase in traffic from a single source -- you need to know immediately. The gateway should integrate with your alerting tools or provide its own notification system. **Log retention.** Compliance frameworks specify minimum retention periods for audit logs. Your gateway's logging solution should support configurable retention and, ideally, archival to long-term storage. **SIEM integration.** For enterprise teams, logs need to flow into a Security Information and Event Management system for correlation with other security data. The gateway should support export to common SIEM platforms through standard formats and protocols. **Sensitive data handling.** Logs should never contain secrets, tokens, or personally identifiable information unless explicitly configured. The gateway should redact or mask sensitive fields by default. Zuplo provides [built-in analytics and logging](https://zuplo.com/docs/articles/log-plugins) with per-consumer attribution. Logs can be exported to external systems for long-term retention and SIEM integration. ## Compliance Certifications When your API handles regulated data, your gateway vendor's compliance posture becomes your compliance posture. ### What to Ask Vendors **SOC 2.** Does the vendor hold a current SOC 2 Type II certification? This demonstrates that they have implemented and maintain controls around security, availability, processing integrity, confidentiality, and privacy. Ask for the latest report and review the scope -- make sure it covers the gateway service specifically. **GDPR.** If you handle data from EU residents, your gateway vendor must support GDPR compliance. Key questions: Where is data processed? Can you configure data residency? Does the vendor act as a data processor, and do they offer a Data Processing Agreement (DPA)? **HIPAA.** For healthcare APIs, ask whether the vendor will sign a Business Associate Agreement (BAA). Understand how Protected Health Information (PHI) is handled as it passes through the gateway. Is it encrypted? Is it logged? Who has access? **PCI-DSS.** If payment card data touches your API, your gateway is in scope for PCI-DSS. Ask what PCI compliance level the vendor holds and whether their infrastructure is validated by a Qualified Security Assessor. **Data residency and access.** Beyond certifications, ask practical questions: Where are the gateway's points of presence? Which employees have access to production systems? How are access controls enforced internally? What is the vendor's incident response process? ## Security Headers HTTP security headers are a simple but effective defense layer. Your gateway should add and enforce them automatically. ### Essential Headers **CORS (Cross-Origin Resource Sharing).** Misconfigured CORS is one of the most common API security issues. The gateway should provide fine-grained CORS configuration: allowed origins, methods, headers, and credentials. Wildcard origins should be flagged as a security risk. **HSTS (HTTP Strict Transport Security).** This header tells browsers to only communicate over HTTPS. The gateway should set this header on all responses with an appropriate `max-age` value. **Content-Security-Policy (CSP).** While more relevant for web applications than pure APIs, CSP headers prevent certain classes of injection attacks. If your API serves any HTML content or documentation, CSP should be configured. **X-Content-Type-Options.** Setting this to `nosniff` prevents browsers from MIME-sniffing responses, which can lead to security vulnerabilities when content types are misinterpreted. **X-Frame-Options.** Prevents your API responses from being embedded in frames, defending against clickjacking attacks. Your gateway should allow you to set these headers globally and override them per-route as needed. ## The Buyer's Security Checklist Use this checklist when evaluating API gateway vendors. Each item represents a capability your gateway should provide or a question your vendor should answer. ### Authentication - [ ] Supports API key authentication with key management (issuance, rotation, revocation) - [ ] Validates JWTs with configurable issuer, audience, and claims checks - [ ] Supports OAuth 2.0 token validation - [ ] Supports mutual TLS (mTLS) for client certificate authentication - [ ] Allows custom authentication policies and middleware - [ ] Integrates with multiple identity providers (Auth0, Okta, Azure AD) - [ ] Enforces role-based access control (RBAC) per route and method - [ ] Supports scoped API keys with per-consumer permissions ### Encryption - [ ] Supports TLS 1.3 by default - [ ] Provides automatic certificate provisioning and renewal - [ ] Enforces HTTPS on all endpoints (no plaintext fallback) - [ ] Encrypts traffic between gateway and origin servers - [ ] Offers certificate pinning for high-security use cases ### DDoS and Abuse Protection - [ ] Supports per-consumer, per-IP, and per-endpoint rate limiting - [ ] Provides IP blocking and allowlisting - [ ] Includes bot detection or integrates with bot protection services - [ ] Enforces request size limits - [ ] Supports geographic traffic restrictions - [ ] Deploys at the edge to absorb attacks before they reach origin ### Input Validation - [ ] Validates requests against OpenAPI schemas automatically - [ ] Performs deep JSON schema validation on request bodies - [ ] Validates required headers and content types - [ ] Rejects unexpected query parameters and path segments ### Audit Logging and Monitoring - [ ] Logs all API requests with timestamps, consumer identity, and response codes - [ ] Attributes requests to specific consumers (not just IPs) - [ ] Supports real-time alerting on anomalies and errors - [ ] Provides configurable log retention periods - [ ] Integrates with SIEM platforms and log aggregation tools - [ ] Redacts sensitive data (tokens, PII) from logs by default ### Compliance - [ ] Holds current SOC 2 Type II certification - [ ] Provides a Data Processing Agreement (DPA) for GDPR - [ ] Supports data residency configuration - [ ] Will sign a Business Associate Agreement (BAA) for HIPAA if needed - [ ] Can articulate PCI-DSS compliance scope and validation level ### Infrastructure Security - [ ] Runs on hardened, regularly patched infrastructure - [ ] Provides network isolation between tenants - [ ] Enforces least-privilege access for internal operations - [ ] Has a documented incident response process with defined SLAs ## How Zuplo Addresses Security Zuplo is built with security as a foundational concern, not an afterthought. **Edge-first architecture.** Zuplo runs on [Cloudflare's global edge network](https://zuplo.com/docs/articles/what-is-zuplo), meaning your API gateway is deployed across hundreds of locations worldwide. DDoS attacks are absorbed at the edge before they reach your infrastructure, and latency is minimized by processing requests close to your users. **Built-in authentication.** [API key management](https://zuplo.com/docs/articles/api-key-authentication), JWT validation, and custom auth policies are all available as composable policies. You can combine multiple authentication methods on a single route and enforce fine-grained access control without writing custom proxy logic. **OpenAPI-native validation.** Zuplo uses your OpenAPI specification as the source of truth. [Request validation](https://zuplo.com/docs/policies/request-validation-inbound) happens automatically against your schema, rejecting malformed requests before they reach your backend. **Comprehensive logging.** Every request is logged with consumer identity, latency, and response details. Logs integrate with external platforms for long-term retention and analysis. **SOC 2 compliant.** Zuplo holds [SOC 2 Type II certification](https://zuplo.com/docs/articles/security), demonstrating audited controls around security, availability, and data handling. A DPA is available for GDPR compliance. **Programmable and auditable.** Because Zuplo configuration is [managed through Git](https://zuplo.com/docs/articles/source-control), every change to your gateway's security policies is version-controlled, reviewable, and auditable. No one can make a silent change to authentication rules or rate limits without it appearing in your commit history. ## Secure Your APIs with Zuplo Security is not a feature you bolt on later. It is the foundation everything else depends on. When you evaluate API gateways, use the checklist above to hold vendors to the standard your infrastructure deserves. If you want an API gateway that was built for security from the ground up -- edge-deployed, SOC 2 compliant, with built-in auth, validation, and logging -- [start with Zuplo today](https://portal.zuplo.com).