- Mais recentes
- Mais votos
- Mais comentários
This will be difficult to unpick without knowing what your WebACL configuration looks like but, at a first guess, as you are working with multiple domains, I would start by validating what domains you have configured in your token settings: https://docs.aws.amazon.com/waf/latest/developerguide/waf-tokens-domains.html#waf-tokens-domain-lists
The issue you're experiencing with "Max challenge attempts exceeded" is related to how AWS WAF Challenge actions work with Single Page Applications (SPAs) or when making cross-domain requests.
When a user clicks on a link that opens your protected page in a new tab, the challenge may not complete properly before your application attempts to load resources. This happens because:
- The AWS WAF Challenge action requires JavaScript execution to complete a "proof of work" and generate a token (cookie called 'aws-waf-token')
- When opening a new tab via a link from another domain, this challenge process can fail if your application makes requests before the challenge completes
To fix this issue, you have a few options:
- Implement the AWS WAF JavaScript integrations in your application:
- Use
AwsWafIntegration.fetchwrapper to ensure the challenge completes before making fetch requests - Or use
AwsWafIntegration.getToken()which returns a promise that resolves when the challenge completes
- Consider adjusting your Challenge rule configuration:
- Rate-limit rules are more effective for triggering challenges against malicious bots
- Avoid triggering challenges based solely on headers or user-agent strings
- Be careful about implementing challenges on non-HTML content or API endpoints
- Ensure the challenge is only applied to appropriate requests:
- The token can only be acquired via HTTP GET requests with the 'Accept' header containing 'text/html'
- Don't configure a Challenge response for non-page requests unless you've already acquired the token
The reason it works on the second attempt is that the browser has already completed the challenge and stored the token as a cookie, which is then used for subsequent requests to your domain.
Sources
Optimizing web application user experiences with AWS WAF JavaScript integrations | Networking & Content Delivery
How to mitigate bot traffic by implementing Challenge actions in your AWS WAF custom rules | AWS Security Blog
DDoS Resilience - Using AWS WAF to protect against DDoS Botnets | AWS re:Post
The other domain is a partner that wants to link to us. I think a solution I found was to disable the challenge attempts if the referer is their domain.
That fixes the immediate problem, but we do still have users that run into this when simply loading the page and I'm not sure how to reproduce their issue. I assume it's a cookie/browser thing, but I don't have steps to reproduce yet, unfortunately.
I was having the same problem and was able to recreate the issue on my iPhone 12 using Firefox, DuckDuckGo, and Brave.
The Athena query below helped tremendously. See here to create the Athena table required for it. It lists the host and all labels associated with Challenge requests from a specified IP address that was receiving the errors.
In my case, I noticed the label awswaf:managed:token:rejected:domain_mismatch. I believe it is related to an ALB redirect going from example.com to www.example.com, but that hasn't been confirmed.
My Fix:
I went to the CAPTCHA/Challenge configuration and added my apex host (example.com) to the Token domains list.
In your case, you might need to add your partner's apex domain also if you're experiencing the domain mismatch error. If not, I believe the query may guide you to a solution. I hope this helps.
Also, rereading best practices may help avoid placing challenges on pages that can't handle the interstitials properly(see below).
-- Athena Query
SELECT
FROM_UNIXTIME(w."timestamp" / 1000) AS time,
h.value AS host,
l.name AS label_name
FROM waf_logs w
CROSS JOIN UNNEST(w.labels) AS t(l)
CROSS JOIN UNNEST(w.httprequest.headers) AS th(h)
WHERE w."date" = '2025/10/07'
AND w.action = 'CHALLENGE'
AND w.httprequest.clientip = '<ip address having issue>'
AND lower(h.name) IN ('host', ':authority')
ORDER BY time DESC
LIMIT 200;
Decide where to run CAPTCHA puzzles and silent challenges on your clients
Configure your Challenge and CAPTCHA use so that AWS WAF only sends CAPTCHA puzzles and silent challenges in response to GET text/html requests. You can't run either the puzzle or the challenge in response to POST requests, Cross-Origin Resource Sharing (CORS) preflight OPTIONS requests, or any other non-GET request types. Browser behavior for other request types can vary and might not be able to handle the interstitials properly.
It's possible for a client to accept HTML but still not be able to handle the CAPTCHA or challenge interstitial. For example, a widget on a webpage with a small iFrame might accept HTML but not be able to display a CAPTCHA or process it. Avoid placing the rule actions for these types of requests, the same as for requests that don't accept HTML.
Conteúdo relevante
- feita há 4 meses
- feita há 6 meses
- AWS OFICIALAtualizada há 4 meses

Thanks, this is helpful, but I don't think it will solve our problem. Our application is not a SPA, and we barely use any JavaScript. I also don't know how our application could be loading code before the challenge attempt completes, since we're doing this in an incognito window that wouldn't have any of our application's code in cache or anywhere else. I like the idea of using rate limit rules instead of the challenges, but we can't because we need protection from orgs that have millions of IP addresses (it's very annoying). Any other ideas?