Simplifying Direct Access Restriction to AWS Application Load Balancer via API Gateway

When an internet-facing ALB is configured behind an API Gateway using an HTTP integration, the ALB becomes publicly accessible. While trusted clients connect to the application through the API Gateway, this setup introduces a significant security risk: the ALB’s public endpoint can be directly accessed, bypassing the API Gateway’s security features.

This lack of restriction leads to several potential vulnerabilities. Maintaining the security and integrity of your application requires preventing direct access to the ALB. By ensuring all traffic flows through the API Gateway, you can enforce critical security features such as request validation, throttling, authentication, and authorization. Without these protections, hackers can exploit vulnerabilities, bypass authentication mechanisms, and overwhelm backend services with excessive load, leading to potential denial-of-service (DoS) attacks.

While AWS provides a solution using REST API Gateway and AWS Web Application Firewall (WAF) to block requests without a unique header, this approach introduces additional complexity and costs. It’s worth mentioning that for use cases requiring advanced security measures such as protection against SQL injection, cross-site scripting (XSS), or bot mitigation, AWS WAF remains a powerful tool.

In this blog, we introduce a simpler and cost-effective alternative. By using custom headers and ALB rule conditions, we achieve the same level of security without relying on AWS WAF. This method works seamlessly for both REST and HTTP API Gateways and significantly reduces operational overhead.

This approach eliminates the need for AWS WAF by leveraging ALB’s content-based routing capabilities. This solution involves:

1. Adding a custom header and value to HTTP requests in API Gateway.
2. Configuring ALB rules to enforce header validation. Only requests with the correct header and value will match the desired ALB rules; all others will hit the default rule.
3. Setting the ALB default rule to return an HTTP error code, such as 403 Forbidden.

Here’s a high-level view of the architecture:

HTTP Request flow.

Step 1: Define a Custom Header in API Gateway

For HTTP API Gateway, use parameter mappings to modify requests sent to the ALB integration.

1. Go to the API Gateway console.
2. Navigate to your HTTP API.
3. In the “Integrations” section, navigate to “Manage Integrations.”
4. Create a parameter mapping to include the custom header and value.

Parameter mapping configuration.

If your API gateway is REST based, follow this link to add a custom HTTP header.

Step 2: Configure ALB Rules

1. Open the ALB configuration in the EC2 console.
2. For each listener rule (except the default rule):

• Add an AND condition.
• Specify “HTTP header” as the condition type.
• Enter the header name and expected value.

3. Set the default rule to return an HTTP error response (e.g., 403 Forbidden).

ALB rule conditions and actions.

To read more about content based routing on ALB, refer this blog article from AWS.

Step 3: Test the Configuration

1. Send a request through the ALB without the custom header. Verify that it triggers the ALB default rule and returns the error response.
2. Send a request through the API Gateway. Verify that it is routed to the application.

This solution simplifies the architecture by removing the dependency on AWS WAF. By leveraging ALB’s built-in content-based routing capabilities, this approach provides a secure and efficient way to restrict direct access to your Application Load Balancer.

If you’d like to know more or are interested in our services, don’t hesitate to get in touch. You can contact us here.