Showing results for 
Search instead for 
Did you mean: 

Case insensitivity in ASM Brute Force username and/or password elements


I have a login page I'm attempting to enable brute force protection for (JSON/AJAX auth type), and it supports username and password JSON elements that are case insensitive from our application's perspective, meaning we expect clients to send them with inconsistent casing. The help text shows that the F5 BIG-IP expects these parameters to be case sensitive, which makes me think that even if we used an ASM policy with case sensitivity disabled during creation, it would still be treated as case sensitive. Frankly even if this did work as a workaround, I'm not sure I'd want to do this because I don't want everything in the policy to be case insensitive - just these few login elements. Also I'm not able to create a "duplicate" login URL where each one uses a different case for the username and/or password elements - the ASM policy prevents this. What is the recommendation for how to implement brute force protection for username and/or password parameters that can be sent with multiple cases?



Hi Colin,

We have the exact same issue/concern regarding the username/password JSON element in the Login page properties. Glad we are not the only ones with this issue. Did you get a response on how to resolve this? Perhaps, opened a F5 support case for this? Let me know when you get a chance on how things worked out for you. Appreciate your time on this.

Thank you!

Hi guys, I'm facing the same issue as you do. Did you get any response from support? This is really unexpected behaviour, when the whole policy is case insensitive.



I never got a response on this question. What I ended up doing was working with our application teams to ensure that our client code would always send the usernames/passwords with a given case, and then I implemented a Brute Force policy for that known-good scenario, and wrote an iRule to deny any requests that do not conform to this casing, knowing that they would all be illegitimate. I'm sure there are other ways of solving this, but I'm still not sure about the "best approach". Another way I considered was having a dedicated ASM policy just for Brute Force where the whole policy defined as case insensitive, and using a Local Traffic Policy that looked for our application's login URIs and using this dedicated policy in that scenario. I hope these ideas help.


Hi Colin, thank you for some ideas how you handled the situation. Problem with your second approach is, that even if the whole security policy is case insensitive, that parameters configured on JSON/AJAX login page are handled as case sensitive. This inconsistency drives me crazy, as there isn't any reasonable solution for this. I am thinking about contacting support to ask them if this is a bug or a feature 🙂 Our application accepts any case for parameter names (eg. pArAmEtEr), but Login page in case insensitive policy expects exact single case format (parameter, or Parameter, whatever I configure there). Thus it is pretty straightforward how to bypass whole bruteforce protection, just by changing the case of parameter name.