Azure WAF JSChallenge- SameSite=Strict cookie breaks replay POST mechanism

Hello akram,

Greetings! Thanks for raising this question in Q&A forum.

You have correctly identified a known behavioral limitation in how Azure Application Gateway WAF's JSChallenge sets its clearance cookie. The core problem is that the appgw_azwaf_jsclearance cookie is issued with SameSite=Strict, which is a browser security policy that prevents the cookie from being sent on cross-context navigations — including the replay POST that the WAF challenge mechanism itself initiates after verification. In simple terms, the browser blocks the cookie from going along on that exact replay request, causing the WAF to see a cookie-less POST and issue a 403. The manual refresh works because that is a same-site GET request where SameSite=Strict is not a barrier. This is indeed a bug — or at the very least a design flaw — in how the WAF sets this cookie.

Here are the steps to work around this and resolve the user experience issue while you wait for a platform-level fix:

Step 1: Confirm the root cause with browser developer tools

Before applying any workaround, quickly confirm this is definitely the SameSite=Strict issue. Open Chrome DevTools → Network tab → reproduce the flow → look at the replay POST request headers. If appgw_azwaf_jsclearance is absent from the Cookie header on that specific POST request, the diagnosis is confirmed.

Step 2: Workaround — redirect instead of replaying the POST

The most effective client-side workaround is to modify the challenge completion script behavior so that instead of replaying the original POST, it issues a GET redirect to the original URL after verification. This way the browser follows a same-site navigation and the SameSite=Strict cookie is sent correctly.

If you have any control over the challenge page or a custom error page, you can intercept the post-verification step and replace the replay POST with:

window.location.href = originalUrl; // GET redirect after challenge completes

This does mean the user's original POST data is lost on that request, but in most cases the user can simply resubmit the form — which is a much better experience than seeing a 403.

Step 3: Workaround — use a WAF exclusion for specific POST endpoints

If the affected pages are known and predictable (such as a login form or a specific API endpoint), you can create a WAF exclusion rule that bypasses the JSChallenge for those specific request paths. Go to:

Azure Portal → Your Application Gateway → Web Application Firewall → Exclusions → Add Exclusion

Set the exclusion to match on the specific URI path of your affected POST endpoints. This reduces the protection on those specific paths but eliminates the 403 loop entirely for your users.

Step 4: Workaround — switch from JSChallenge to CaptchaChallenge for POST-heavy flows

If JSChallenge is not a strict requirement, consider switching the challenge action to CaptchaChallenge for rules that trigger on POST requests. The Captcha challenge flow uses a different cookie mechanism that handles the replay POST more gracefully in most browsers.

Step 5: Report this as a bug to Microsoft

This is a genuine platform bug — the WAF's own replay POST mechanism is defeated by the cookie's own SameSite=Strict attribute, which means the WAF is essentially breaking its own challenge flow in certain browser contexts. Please report this formally:

Azure Portal → Help + Support → New Support Request and fill in:

• Issue type: Technical
• Service: Azure Web Application Firewall
• Problem type: WAF Policy and Rules
• Problem subtype: JSChallenge behavior issue
• Severity: B (Moderate)

In the description include:

• The exact reproduction steps (your expected vs actual behavior above is perfect)
• The cookie attribute issue: appgw_azwaf_jsclearance is set with SameSite=Strict, breaking the WAF's own replay POST mechanism
• Your Application Gateway name, WAF policy name, and region
• Request that the team change the cookie to SameSite=Lax or SameSite=None; Secure to allow the replay POST to succeed

The correct fix on Microsoft's side is simple — changing the SameSite attribute on the clearance cookie from Strict to Lax would resolve this entirely without any security regression, since the cookie is already scoped to the same domain.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

I think JSChallenge cookie attributes, including SameSite, are not configurable in any Azure public documentation, and the only documented actions are to remove that POST path from JSChallenge in the WAF policy and to use a support request when further investigation is needed.

Hey akram , thanks for raising this—what you’re seeing is a known side effect of the JS Challenge cookie being set with SameSite=Strict. By spec, Strict cookies are only sent on “first-party” top-level navigations (mostly GETs), so the in-page POST replay that the challenge script issues doesn’t include the cookie and you get a 403. When you manually refresh the page (a top-level GET), the cookie does go, so it then works.

Here are your main options:

1. Workaround via a rewrite rule • In the Azure portal, go to your Application Gateway → “Rewrites” → add a new rule. • Match on Set-Cookie headers for appgw_azwaf_jsclearance • Replace SameSite=Strict with SameSite=None; Secure (or SameSite=Lax) That way the cookie will ride along on the JS challenge-issued POST.
2. Change the client-side flow • Instead of doing an XMLHttpRequest/fetch to replay the POST, do a full top-level redirect back to the original URL. Strict cookies do get sent on navigations.
3. Track the feature request • This is currently the behavior in JS Challenge on Application Gateway (preview). We’ve got it on file with the WAF engineering team, and they’re evaluating making the default SameSite less strict so replay POSTs work out of the box.

If the above steps didn't helped, please share the below information.

• Which browser and version are you testing with?

• Is your original page request a form POST or an API call via XHR/fetch?

• Can you share a HAR or network trace of the challenge flow (challenge page → verify → replay)?

Hope that helps you unblock!

Kindly let us know if the above helps or you need further assistance on this issue.

If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".

We are facing the same issue and assuming that the issue is related to http2.

Despite the Cookie settings with SameSite=Strict or SameSite=None; Secure the issue still persists.

When forcing the browser to use http 1.1 the JSChallenge is working as expected and access is granted.