ALB URL rewrite transform appears to execute before WAF inspection, contrary to expected behavior

Question

**Background**

I have an Application Load Balancer (ALB) with AWS WAF (Web ACL) attached. I configured a WAF rule called BlockInvalidPath that inspects the URI path and blocks requests that do not match a valid path regex pattern. The ALB also has a Listener Rule with a URL rewrite transform configured as: match ^/.*$, replace with /

**Expected behavior**

WAF is expected to inspect the original, unmodified URI path before any ALB transforms are applied. The AWS documentation states that transforms rewrite requests "before they are routed to targets," implying WAF — which sits upstream of the routing decision — should see the raw request. Under this assumption, a request to /api/v1/a should be evaluated by WAF as /api/v1/a

**Actual behavior**

WAF only ever sees / as the URI path, regardless of the original request path. This is confirmed in WAF Sampled Requests — every entry shows URI /, even for requests sent to /api/v1/a. As a result, the WAF regex rule never matches the intended paths, and all traffic is either incorrectly blocked or incorrectly allowed depending on the rule logic.

**Steps to reproduce**

1. Create an ALB with a WAF Web ACL attached (REGIONAL scope, same region as ALB).
2. Add a WAF rule that inspects URI path using a regex pattern set (e.g. ^/api/v[0-9]+/[a-zA-Z]+$).
3. On the ALB Listener Rule, add a URL rewrite transform: match ^/.*$, replace with /.
4.Send a request to a path matching the WAF regex, e.g. curl http:///api/v1/a.
5. Check WAF Sampled Requests — the URI logged is /, not /api/v1/a.

Florian Turnwald · Accepted Answer

Regarding the comment from drona, respectively *"A rule transform rewrites inbound requests before they are routed to targets."* ->

![Evidenz](/media/postImages/original/IMSHLVnrrcQ-iodGPQj8FZgQ)

Source: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/rule-transforms.html

**I think it's important to note, why the documentation is often misunderstood**

The sentence quoted in the document, "*A rule transform rewrites inbound requests before they are routed to targets*", is technically accurate but "misleading" in a security context. It simply confirms that the final destination (e.g., an EC2 instance or Lambda function) will receive the modified URL. However, **it does NOT explicitly state that WAF inspection happens before this transformation**. In reality, AWS WAF inspection occurs after the ALB has evaluated the listener rules and applied any associated transforms. Consequently, the WAF is inspecting the request in its "post-rewrite" state, not the original "raw" request sent by the client.

**As to my understanding:** The documentation link primarily focuses on ALB Rule Transforms. The confusion arises because WAF is an integrated service that the ALB invokes after it has already begun processing the request. Because the URL Rewrite is an Action triggered by the rule match , the ALB modifies the request's URI metadata before handing it over to the WAF engine for inspection. Consequently, while the WAF documentation says it inspects the "URI," it is only seeing the URI that exists at that specific point in the ALB's internal workflow - which is the post-rewrite version.

**The Impact (and benefit) of Moving WAF to the Edge (CloudFront)**
If you deploy AWS WAF on CloudFront (Global Scope) instead of the ALB, the architectural issue described in the document is resolved. In this configuration, the WAF inspects the request at the Edge location before it ever reaches the Application Load Balancer

**Request Flow with CloudFront and ORA**
When using CloudFront with an Origin Request Policy (ORA) and a WAF, the sequence of events changes to your advantage:

- **Step 1:** Edge Inspection: The CloudFront WAF receives the "raw" request from the client. At this stage, the URI path is still the original version (e.g., `/api/v1/a`).
- **Step 2:** WAF Evaluation: Your regex rules can successfully match the original path because no transforms have been applied yet.
- **Step 3:** Forwarding to Origin: If the WAF allows the request, CloudFront forwards it to the ALB based on your Origin Request Policy.
- **Step 4:** ALB Rewrite: The ALB receives the validated request, evaluates its own Listener Rules, and performs the URL rewrite (e.g., `/api/v1/a` to `/`).
- **Step 5:** Target Delivery: The modified request is then sent to the backend target.

So, by placing the WAF at the CloudFront level, the ALB acts safely as the "internal" routing engine, knowing that the request has already been "scrutinized" in its original state.

Florian Turnwald · Answer

In the Application Load Balancer (ALB) architecture, the URL Rewrite action is processed during the Rule Evaluation phase. When a request matches a listener rule that contains a rewrite transformation, the ALB modifies the request metadata (the URI path) immediately to prepare it for routing.

The **AWS WAF inspection occurs AFTER the ALB has finished evaluating listener rules** and has applied any associated transformations. Therefore, the WAF Web ACL receives the "post-rewrite" URI for inspection, not the original "raw" URI sent by the client. This explains why your WAF logs and sampled requests show / regardless of the input path.

**Key Takeaway: Internal Request Flow**

The phrase "before they are routed to targets" in the documentation means that the target (e.g., EC2, Lambda) receives the modified URI. However, the WAF does not sit upstream of the ALB's internal rewrite engine. Internally, the sequence is:

**1. Rule Matching:** ALB identifies the matching Listener Rule.

**2. Transformation:** ALB applies the URL Rewrite (e.g., `/api/v1/a` -> `/`).

**3. WAF Inspection:** ALB hands the transformed request to WAF.

**4. Forwarding:** If WAF allows, the request is forwarded to the Target.

*"A rule transform rewrites inbound requests before they are routed to targets."*

source: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/rule-transforms.html

**I think the recommended solutions here are:**

To achieve your goal of blocking invalid paths while still using rewrites, consider these three approaches:

**1. Use Separate ALB Rules for Validation (The "Block-First" Approach)**

Instead of relying on WAF for the regex path validation, use the ALB's own routing capabilities to perform the check before the rewrite rule is hit:
- **Priority 10:** Create a rule that matches your valid regex (e.g., Path is `/api/v1/*`). **Action:** Forward to target group (with or without rewrite as needed).
- **Priority 20 (Catch-all) Action:** Return Fixed Response **403** for any path that did not match the valid pattern in Priority 10.

**2. Move WAF to CloudFront (Global Scope)**

If you require WAF to inspect the original, unmodified URI, you should deploy Amazon CloudFront in front of your ALB and attach the WAF Web ACL to the CloudFront distribution.
- CloudFront WAF inspects the request at the Edge, before it reaches the ALB.
- The ALB can then perform the URL Rewrite safely, knowing the request has already been validated in its original state.

**3. Adjust WAF Logic via Headers**

If the rewrite is always to `/`, you can no longer use the `URI Path` field in WAF for granular validation. You would need to check if the original path is preserved in a header. While the ALB doesn't automatically move the old path to a new header during a rewrite, if your client sends the original path in a custom header, you could inspect that instead.

**PS**: Since WAF inspection on an ALB occurs after the listener rule has been evaluated and the associated 'Action' (including the transform) has been initiated, the WAF is inspecting the request in its transformed state

ALB URL rewrite transform appears to execute before WAF inspection, contrary to expected behavior

Add your answer

Relevant content