Web Application Firewalls

Configuring Zuplo with Akamai App & API Protector

Applies to
Gatewayruntime for API, AI, and MCP gateways
Hosting
Managed EdgeManaged DedicatedSelf-Hosted

Akamai App & API Protector runs at Akamai edge locations. Zuplo can be configured to run as a custom origin behind Akamai.

Securing Zuplo from Direct Access

With any WAF product, you will want to ensure that network traffic can't bypass your WAF and hit your Zuplo Gateway directly. To do that, every request from Akamai must prove that it came from your Akamai property, not just from Akamai's network.

Use one of these:

MethodHow it works
Shared secret headerAkamai adds a secret header to every request it forwards. The gateway rejects requests without it.
Mutual TLSAkamai presents a client certificate when it connects to the gateway. The gateway rejects connections without one.

Don't rely on Akamai IP addresses alone. Akamai's edge IP ranges, including the Origin IP ACL ranges, are shared by every Akamai customer. Anyone with an Akamai account can configure a property that points at your gateway and sends traffic from those addresses. Akamai's own guidance states that Origin IP ACL "isn't a substitute for authentication". See IP-based restrictions.

The rest of this section summarizes Akamai's recommendations for securing an origin. For the full details, see the Akamai documentation.

Shared Secret Header

A shared secret header is the simplest option, and it works on every Zuplo plan.

In Akamai, use the Modify Incoming Request Header behavior in Property Manager to add a header, such as x-akamai-auth, with a long random value. Store the same value in Zuplo as a secret environment variable named AKAMAI_SECRET_HEADER_VALUE.

In Zuplo, add a small custom code policy that rejects requests without the header and secret value.

TypeScriptmodules/require-akamai-header.ts
import { environment, HttpProblems, ZuploContext, ZuploRequest, } from "@zuplo/runtime"; export default async function policy( request: ZuploRequest, context: ZuploContext, ) { const headerValue = request.headers.get("x-akamai-auth"); if (!headerValue || headerValue !== environment.AKAMAI_SECRET_HEADER_VALUE) { return HttpProblems.unauthorized(request, context); } return request; }
JSONCode
{ "name": "allow-akamai-custom-header", "policyType": "custom-code-inbound", "handler": { "export": "default", "module": "$import(./modules/require-akamai-header)" } }

Add this policy first in the inbound policy list of every route. With it in place, only requests that carry the secret value reach your Zuplo Gateway. Treat the value like any other credential: rotate it periodically by updating the Akamai behavior and the environment variable together.

Mutual TLS (mTLS)

Mutual TLS authenticates Akamai with a certificate instead of a header value. It's the strongest option, and there's no secret in the request for anything downstream to log or leak.

  1. In Akamai, upload a client certificate to the mTLS Origin Keystore and attach it to your property's origin.
  2. In Zuplo, upload the CA certificate that issued it and add the mtls-auth-inbound policy to your routes. See Client mTLS authentication.

Use a CA that issues certificates only for Akamai. CA certificates in Zuplo are scoped to your account, so any client certificate that the CA issues passes the check.

IP-Based Restrictions

Akamai maintains a list of IP addresses that you can use to restrict access to your Zuplo Gateway. This is a good way to ensure that only Akamai can access your gateway. However, Akamai is a multi-tenant service, so this method isn't enough on its own to keep unauthorized traffic from reaching your gateway. Use it in addition to a shared secret header or mTLS, never instead of one.

  1. In Akamai, add the Origin IP Access Control List behavior to your property, in the same rule as the Origin Server behavior. Without this behavior, requests to your origin can come from any Akamai edge address, not just the Origin IP ACL ranges.
  2. In Zuplo, add the IP Address Restriction policy with the Origin IP ACL ranges. The ranges below were current when this page was written. Check Akamai's list before you use them.
JSONCode
{ "name": "allow-akamai-ips", "policyType": "ip-address-restriction-inbound", "handler": { "export": "IpAddressRestrictionInboundPolicy", "module": "$import(@zuplo/runtime)", "options": { "allow": [ "2.16.0.0/13", "23.0.0.0/12", "23.192.0.0/11", "23.32.0.0/11", "95.100.0.0/15", "184.24.0.0/13", "2a02:26f0::/32", "2600:1400::/24", "2405:9600::/32" ] } } }

Akamai changes these ranges from time to time and announces the changes through the Firewall Rules Notification tool. Subscribe to it so you can update the policy before old ranges are retired.

Site Shield is an alternative to Origin IP ACL that uses a smaller set of addresses. Like Origin IP ACL, it restricts where traffic comes from but doesn't authenticate your property, so pair it with a shared secret header or mTLS.

Last modified on