aws-waf-token cookie?Short answer: aws-waf-token is the cookie AWS WAF sets when a client passes a challenge. The token inside it is minted by the challenge script, is tied to the domain and to a short time window, and is worthless without the same browser context that solver produced it in. Teams that fail at AWS WAF almost always fail on three details rather than on cryptography.
The value is a JSON blob, base64 or plain depending on the endpoint, with fields such as action, captcha_voucher, challenge, existing_token and domain. The ones that matter for re-use:
| Field | Why it matters |
|---|---|
domain | The token is bound to the host it was issued for. Moving it to another subdomain invalidates it. |
challenge / captcha_voucher | Proves the challenge or CAPTCHA was solved in this window. It is the part the WAF re-verifies. |
existing_token | An earlier token this one was derived from. Chained reuse is what lets a session keep working for longer than one window. |
AWS WAF uses aws-waf-token on most properties, but some integrations use AWSWAFTOKEN or a custom cookie name configured on the web ACL. If your client writes the wrong name, the header goes out and the WAF ignores it — no error, just another challenge. Read the Set-Cookie name from the challenge response instead of hard-coding it.
The challenge is delivered by a JavaScript resource under a path that includes a rotating identifier, served from the site's own domain. A solving API needs that URL to run the challenge; a token cannot be produced from the page URL alone. This is the field people leave out of the request, and it is why they get a token back that the site rejects. On the SolveHub API the field is task.scriptURL — it is documented on the AWS WAF endpoint.
AWS WAF challenge tokens are typically good for around three minutes of issuance, and the WAF keeps track of when the client last proved itself. Long jobs need a refresh path, not a longer-lived token: keep the session that produced the token alive, and re-solve before it goes stale rather than after the first 403. If a job takes longer than the window, solving once at the start is a plan that fails at minute four.
Both set the same cookie family but they are different tasks. The challenge is a silent proof-of-work style check with no user interaction; the CAPTCHA is the visible puzzle and returns a voucher. A solver must know which one the site is serving, because the answer payload differs. Sending a challenge solution where a CAPTCHA voucher is expected produces a token the WAF rejects without explanation.
aws-waf-token on requests to static assets — some web ACLs scope the rule to the whole host.Does the aws-waf-token expire? Yes. It is typically valid for about three minutes from issuance, and the WAF expects a fresh proof of challenge as a job continues. Plan for a refresh loop, not a one-off solve.
Can I use one token for many requests? Within its window, from the same client, yes. Across workers or IPs, no — the WAF tracks the last proof per client and treats parallel reuse as replay.
Why is my token rejected even though it is fresh? Usually one of three reasons: the cookie name does not match what the site actually set, the token was minted for a different domain, or the answer was a CAPTCHA voucher for a challenge rule, or the reverse.