WAF custom rule for rate limiting only blocking every other request once limit is reached.

Steven Bruce 5 Reputation points

This is the rule that is being applied:
👁 User's image

This is an example of the output:

👁 User's image

Notice that the status codes alternate between 401 and 429. The rule is kicking in but does not persist. There are other articles that indicate others are observing this issue.

Is this a known issue? Is there the intention to fix it?

  1. Vallepu Venkateswarlu 10,000 Reputation points • Microsoft External Staff • Moderator

    Hi @ Steven Bruce,

    Welcome to Microsoft Q&A Platform.

    This is not a bug. It is expected behavior based on how Azure WAF rate limiting works.

    The alternating 401 and 429 responses occur because of how the rate limit counter and its one-minute evaluation window function

    You configured a rate-limit rule with the following settings:

    • Threshold: 20 requests
    • Duration: 1 minute
    • Condition: RequestUri contains /login
    • Action: Deny

    When requests are sent to /login, the first 20 requests within one minute are allowed and forwarded to the backend, which returns 401 (authentication failure).

    Once the 20-request limit is exceeded, WAF blocks further requests and returns 429 (Too Many Requests).

    As older requests fall out of the one-minute sliding window, the count drops below the limit, requests are allowed again (401), and if traffic continues, the limit is exceeded again (429).

    The alternating 401 and 429 responses are expected behavior due to rate limiting.

    I hope this information helps resolve your issue. Please feel free to ask if the provided solution does not help or if you have any additional questions.

    Please "upvote" if the information helped you. This will help us and others in the community as well.

  2. Steven Bruce 5 Reputation points

    Thanks for the response.

    Regarding this statement: "As older requests fall out of the one-minute sliding window, the count drops below the limit, requests are allowed again (401), and if traffic continues, the limit is exceeded again (429).", this is not what is happening in my case. The 100 requests were all completed within around 30 seconds so the sliding window is not relevant here.

    That said, I think we're ultimately saying this is how the rate limiting function works and it will limit requests where the rule is breached. I was expecting it to block all subsequent requests until the number of requests within the sliding window was less than the threshold.

    Thanks again for the reply.

  3. Vallepu Venkateswarlu 10,000 Reputation points • Microsoft External Staff • Moderator

    Hi @ Steven Bruce

    Thanks for you response.

    Please share the requested details In private message fir further troubleshoot.

  4. Himanshu Arora 0 Reputation points

    Hi @Steven Bruce ,
    Did you get a solution to your concern? Let me know, I am facing the same issue.

Sign in to comment

1 answer

  1. David Broggy 6,801 Reputation points • MVP

    Hi Steven, that's how the DDoS works, it's a rate limiter, not a blocker.

    You will need an IP blacklist in order to do what you want.

    Instead of relying on WAF's inconsistent rate limit counter, you use two rules working together — your origin detects the abuse and signals the WAF, and the WAF's match rule (which has no distributed counter problem) does the blocking.

    Step 1 — Origin adds a response header when rate limit is hit

    In your application, track login attempts per IP. When an IP exceeds your threshold, add a custom header to the response, for example:

    X-Block-Client: true

    Your app already has consistent server-side state (Redis, memory cache, database), so this counter will be accurate.

    Step 2 — Create a WAF Match rule to block on that header

    In Azure Front Door WAF, create a second custom rule:

    • Rule type: Match (not Rate limit)
    • Priority: 0 (higher than your rate limit rule)
    • Condition:
      • Match variable: ResponseHeader
        • Header name: X-Block-Client
          • Operator: Contains
            • Match value: true
            • Action: Deny traffic (returns 429 or 403)

    Step 3 — Strip the header before it reaches the client

    Make sure Azure Front Door strips X-Block-Client from the response before it's sent to the end user, so you're not leaking internal signaling. You can do this via a Front Door Rules Engine action to remove the response header.

    Why this works better

    Match rules in Azure WAF evaluate a simple condition on the current request/response — there's no distributed counter involved, so the block is consistent on every single request once your origin has flagged that IP. The unreliable part (counting) moves into your application where you have full control over it.

    The main tradeoff is that the first ~20 requests (or however many your app allows) still reach your origin before the block kicks in. But that's actually fine for login protection — you want your app to be the authoritative source on whether an IP should be blocked, and the WAF then enforces it at the edge for all subsequent requests.

    Hope that helps.

    1. Steven Bruce 5 Reputation points

      I will have a look into these options.

      To confirm, the options to implement the desired functionality of blocking requests when the threshold has been exceeded in a sliding window, needs to be implemented at the application level?

    2. Ganesh Patapati 11,915 Reputation points • Microsoft External Staff • Moderator

      Hello Steven Bruce

      Thanks for the response!

      To help troubleshoot the issue further, can we set up a call to discuss and resolve your query? 

      Please share the requested details in a private message.

    3. Ganesh Patapati 11,915 Reputation points • Microsoft External Staff • Moderator

      Hello Steven Bruce

      Thanks for the response!

      To help troubleshoot the issue further, can we set up a call to discuss and resolve your query? 

      Please share the requested details in a private message.

    4. Ganesh Patapati 11,915 Reputation points • Microsoft External Staff • Moderator

      Hello Steven Bruce

      Thanks for the response!

      To help troubleshoot the issue further, can we set up a call to discuss and resolve your query? 

      Please share the requested details in a private message.

    Sign in to comment
Sign in to answer

Your answer