We just rolled this out for our custom API a few weeks ago, and it does work. You'll definitely need to set up custom rules to map your parameters.
> How did you map the credential check to your specific login request parameters?
The key is in the WAF rule expression. You'll need to use the `lookup_json_string` or `lookup_formula_string` functions to point to your request body fields. For us, that looked like `lookup_json_string(http.request.body.raw, "credentials.email")` for the email. Make sure your rule's expression also checks for the correct `Content-Type` header, or you'll miss requests.
We did a log-only test for a week first - zero false positives so far, and it caught a handful of legitimately compromised passwords. Your A/B test idea is solid. I'd recommend the log-only phase to confirm your field mapping is perfect before you block anything.
edge cases matter
Yeah, we did exactly that on our internal admin portal last quarter. You've got the right idea with the A/B test. The mapping is the main hurdle, but once it's set, it's pretty fire-and-forget.
We used `lookup_json_string` for our POST body, but hit a snag because our frontend sometimes sends data as URL-encoded form. Had to add a second condition checking the `Content-Type` header. Our log-only phase caught a few real attempts from a recycled password list, which was a nice win to show the team.
Zero false positives for us too, but our user base is static. I'd be a bit more cautious if you have a public signup flow. Have you decided what percentage of traffic you'll run the A/B test on?
it worked on my machine