AWS WAF is blocking legitimate sign-ins, what are my options?

If AWS WAF is blocking legitimate sign-ins, your options are usually to reduce false positives without removing protection entirely. The best approach depends on which WAF rule is triggering and what part of the login flow it’s hitting.

Practical options

1) Identify the exact blocking rule

Check WAF logs / sampled requests / CloudWatch metrics to find:

• the rule name
• the request pattern being blocked
• whether it’s happening on:
  • the login page
  • the POST /auth request
  • a CAPTCHA/challenge response
  • a specific country/IP/user agent/device

This is the most important first step because the fix differs by rule type.

---

2) Add an exception / scope-down for the sign-in endpoint

If the rule is too broad, you can often:

• exclude the login path (for example /signin, /login, /auth/*) from that rule
• apply the rule only to other paths
• use a scope-down statement so the rule doesn’t inspect the sign-in request

This is common when the login form has:

• long tokens
• unusual payloads
• encoded fields
• redirects that look suspicious to generic protections

---

3) Tune the specific managed rule

If a managed rule group is causing the issue, you can:

• set it to Count mode temporarily to verify impact
• override the individual rule action
• exclude specific subrules
• lower sensitivity if it’s a rate-based or reputation rule

This lets you keep the rule group but avoid the false positive.

---

4) Create an allow rule for trusted traffic

If legitimate sign-ins come from a known source, you can create a higher-priority rule to allow:

• your corporate IP ranges
• VPN egress IPs
• trusted partner networks
• specific user agents or headers if appropriate
• authenticated users after a certain step in the flow

Be careful: allowlisting by IP can be fragile if users are on mobile or dynamic networks.

---

5) Fix bot / rate-limit false positives

If WAF is blocking real users because it thinks they’re bots or abusive:

• raise the threshold on rate-based rules
• exempt the auth endpoint from rate limiting
• adjust bot management settings
• allow the sign-in flow after passing a challenge

This is especially relevant during:

• password resets
• SSO redirects
• repeated login retries
• MFA step retries

---

6) Use CAPTCHA or Challenge instead of Block

For suspicious but not clearly malicious traffic, consider:

• Challenge: verify the client, but don’t hard-block immediately
• CAPTCHA: useful if humans can solve it but bots shouldn’t

This is often a good compromise for login pages.

---

7) Tighten the rule only on the risky parts

If the sign-in page itself is legitimate but some parts are risky, you can:

• inspect only certain headers/cookies
• exclude specific query strings
• ignore known-safe POST fields
• use JSON body inspection carefully

This helps if login requests are being flagged because of large cookies, tokens, or encoded parameters.

---

8) Coordinate with your identity provider

If you use:

• Cognito
• Okta
• Auth0
• Azure AD / Entra ID
• another SSO provider

make sure the WAF allows:

• redirects to/from IdP domains
• callback URLs
• POSTbacks
• MFA challenge requests
• any required cookies or headers

---

9) Temporarily switch the rule to Count and monitor

A safe troubleshooting pattern is:

1. change the blocking rule to Count
2. observe login success/failure
3. confirm false positives
4. then add a targeted exception
5. switch back to Block

This avoids broadly weakening security.

---

10) Revisit application behavior

Sometimes the app itself triggers WAF:

• malformed requests
• huge headers/cookies
• invalid content types
• unusual redirect loops
• repeated submissions caused by front-end retries

Fixing the app can eliminate the WAF issue without relaxing protections.

---

Recommended path

If you’re not sure where to start:

1. Check WAF logs to identify the rule
2. Put that rule in Count mode
3. Add a narrow exception for the sign-in route or legitimate source
4. Re-enable blocking with the exception in place

---

If you want, I can help you narrow it down

If you share:

• the WAF rule name
• whether it’s AWS managed rules, bot control, rate-based, or custom
• the sign-in URL pattern
• and an example of the blocked request fields

…I can suggest the safest specific fix.