How to add WAF and DDoS protection for APIs

TLDR

1. APIs face application-layer threats that standard network firewalls are not built to handle

2. A WAF (Web Application Firewall) filters malicious HTTP/S traffic, blocking injection attacks, schema abuse, and OWASP Top 10 vulnerabilities at the request level

3. DDoS protection absorbs and deflects high-volume traffic floods before they exhaust your API infrastructure

4. Both layers must be placed correctly in your API traffic flow at the edge or gateway level to be effective.

5. Most cloud providers offer managed WAF and DDoS services that integrate directly with API gateways

Start securing your APIs the right way. Book a demo

Why APIs need dedicated WAF and DDoS protection?

APIs are the primary attack surface in modern enterprise architecture. Unlike traditional web pages, APIs expose structured endpoints that accept and return sensitive data, making them attractive targets for both targeted exploits and volumetric attacks. Standard network-layer firewalls inspect IP headers and ports. They are not equipped to parse API payloads, validate schema conformance, or detect credential abuse patterns.

Two distinct protection layers address two distinct threat categories:

• WAF (Web Application Firewall): Inspects and filters application-layer traffic, blocking threats like SQL injection, XSS, and OWASP Top 10 vulnerabilities before they reach your backend
• DDoS protection: Detects and absorbs traffic floods that attempt to exhaust API server capacity at the network layer (L3/L4) or application layer (L7)

These two tools are not interchangeable. Effective API security requires both layers deployed and tuned at the right position in your architecture.

What a WAF does for your APIs

A Web Application Firewall sits between external clients and your API backend. It inspects every incoming request against managed and custom rules, allowing legitimate traffic through and blocking patterns that match known threats. For APIs specifically, a WAF validates whether requests conform to the expected schema and rejects those that deviate from the API contract.

How to add WAF protection to your APIs

WAF configuration follows a consistent pattern regardless of whether you're deploying on AWS, Azure, or Cloudflare. The goal is to associate a WAF policy with your API endpoint or gateway so that all inbound traffic passes through inspection before reaching your application layer.

Step 1: Define your API entry point

Place your WAF in front of your API gateway or load balancer. On AWS, associate your WAF web ACL with an API Gateway stage or a CloudFront distribution. On Azure, WAF policies attach to Azure API Management via Azure Front Door or Application Gateway. Placement determines which traffic the WAF inspects. If placed too deep, attack traffic may reach your backend first.

Step 2: Enable managed rule groups

Start with platform-managed rule sets before writing custom rules. AWS provides managed rule groups covering OWASP vulnerabilities, known bad IPs, and bot signatures. Azure WAF supports the OWASP Core Rule Set (CRS) 3.2 and above. These managed rules require minimal configuration and cover the majority of common API attack patterns immediately on activation.

Step 3: Add API-specific custom rules

Beyond the managed defaults, add rules tailored to your specific API contracts:

• Block requests with unexpected HTTP methods (reject TRACE or CONNECT on REST endpoints)
• Reject payloads exceeding defined size thresholds for specific endpoints
• Validate that required headers such as Authorization and Content-Type are present
• Restrict internal APIs to known partner IP ranges only

Step 4: Deploy in detection mode first

Always run WAF in detection (count) mode before switching to blocking mode. Run it for several days across staging traffic and monitor for false positives. Once you're confident the rule set is accurate, switch to prevention mode. This step prevents accidental disruption to legitimate API consumers. Solid API gateway security practices always include a validation phase before enforcement.

Step 5: Route WAF logs to your observability stack

Connect WAF logs to your SIEM or API analytics platform so you have visibility into what is being blocked and why. Security rules that aren't monitored become stale quickly as your API contracts evolve and new endpoints go live.

How to add DDoS protection to your APIs

DDoS attacks targeting APIs fall into two categories: volumetric floods at L3/L4 that saturate bandwidth, and application-layer attacks at L7 that send high volumes of valid-looking requests to exhaust processing capacity. Your protection strategy needs to cover both, as each requires a different mitigation approach.

Step 1: Enable baseline DDoS protection

Cloud providers include baseline DDoS protection by default. AWS Shield Standard is automatically active for API Gateway and CloudFront deployments. Azure DDoS Network Protection covers resources in protected virtual networks. Enable and confirm these services before configuring anything else. They handle the most common volumetric attack patterns at no additional cost.

Step 2: Configure rate limiting at the gateway level

Rate limiting is your primary defense against L7 DDoS. Set limits per IP address, per API key, and per consumer tier. Any request flood that stays below WAF detection thresholds will be caught here. Configure API throttling alongside rate limiting so excess requests are queued or rejected gracefully rather than crashing your backend under sudden load.

Step 3: Upgrade to managed DDoS services for critical APIs

For APIs handling financial transactions, healthcare data, or high-volume partner integrations, baseline protection is insufficient. Consider:

‍

Step 4: Add geo-blocking and ASN rules

Block traffic from geographic regions or Autonomous System Numbers (ASNs) with no legitimate business reason to access your APIs. ASN-based rules are more durable than IP lists because they restrict entire network providers rather than individual addresses that rotate frequently.

Step 5: Test under simulated load

Run DDoS simulation tests in a controlled staging environment before production. AWS and Azure both provide structured testing processes for this. Confirm that your rate limiting and throttling engage correctly under sustained synthetic load before facing a real incident.

WAF and DDoS best practices for API teams

WAF and DDoS tools are a starting point, not a finish line. Most security gaps occur not because tools are absent, but because they are misconfigured, unmonitored, or not updated when API contracts change. Treat your WAF and DDoS configuration as infrastructure that requires the same lifecycle discipline as your APIs.

Key practices to maintain:

• Keep rule sets current: Custom WAF rules need review whenever your API specifications change or new endpoints are deployed
• Enforce consistent policies across all gateways: If you run APIs across multiple gateways, centralize API security policy enforcement so rules don't diverge across environments
• Combine WAF with zero trust: WAF filters inbound request content, but zero trust ensures that traffic passing WAF inspection is still authenticated and authorized on every call
• Monitor false positive rates: Overly aggressive WAF rules block legitimate consumers. Review blocked request logs regularly.
• Add behavioral analytics: To protect APIs from abuse and bot traffic, combine WAF rules with behavioral detection that goes beyond simple IP and rate checks
• Review API security best practices for a complete checklist that extends beyond WAF and DDoS configuration alone

How DigitalAPI helps enforce WAF and DDoS policies at scale

Enterprises running APIs across multiple gateways face a specific challenge: WAF and DDoS policies configured on one gateway don't automatically carry over to another. Teams end up managing separate rule sets across AWS, Azure, Kong, and Apigee, which creates inconsistencies at exactly the points attackers probe.

DigitalAPI's API governance layer and API gateway manager let security teams define and propagate security policies centrally, across all gateway environments, without configuring each one individually. The Helix Gateway includes built-in policy enforcement for rate limiting, authentication, and security controls out of the box.
‍

Frequently Asked Questions

1. Can a WAF fully replace DDoS protection?

No. A WAF inspects and filters application-layer request content such as SQL injection or schema violations. DDoS protection handles volumetric attacks designed to exhaust bandwidth or server capacity through sheer request volume. Both threat types are real and operate at different layers. A WAF alone leaves you exposed to flood-based attacks that bypass content inspection entirely, and DDoS protection alone does nothing for injection-style exploits.

2. Where should a WAF be placed in an API architecture?

A WAF should sit in front of your API gateway or load balancer, as close to the edge as possible. The CDN or reverse proxy layer is the ideal placement point. Malicious traffic is blocked before it reaches your application servers. This reduces backend processing load and contains the impact of any rule that allows something through inadvertently.

3. Does rate limiting count as DDoS protection?

Rate limiting is a key component of L7 DDoS defense, but it does not protect against L3/L4 volumetric attacks. It is also reactive: it limits damage once a flood begins, but does not absorb traffic before it hits your infrastructure. Dedicated DDoS protection handles the traffic absorption layer that rate limiting cannot address on its own.