Policy Building - 'Policy is Case Sensitive'
Jun 11, 2025
Policy Building - 'Policy is Case Sensitive'
When building a new ASM policy, one of the lesser-known but important advanced options is “Policy is Case Sensitive.” You’ll find this in the Advanced Settings section near the bottom of the policy creation page. Here I will give some practical tips on how to use this setting.
Enabling this setting means that parameter names, URLs, and other entities will be matched with case sensitivity. For example, /Login
and /login
will be treated as two distinct entities.
This setting can't be changes in the GUI or CLI once selected, so it is important to get it right on the policy creation. Note there is a non standard way to change this, that I will cover at the end.
How to tell is the application is case sensitive
Go to the application and find a working URL and also if possible a working QueryString or PostData parameter.
Say the domain is exampleapp.com and the test URI is /faqs/
try these two requests and see if you get the exact same response from the server, if you do get the same response, then the app is NOT case sensitive as both cases has produce the same response from the server
exampleapp.com/faqs/
exampleapp.com/Faqs/ (uppercase F)
If there either any different response of any kind, including a 404 type response or even a 500 response, then the application is case sensitive, and this should be reflected in the ASM policy settings.
This can significantly impact how the policy behaves:
-
It’s useful when protecting legacy applications or APIs where different casing is intentionally used to represent different functionality.
-
It can also lead to unexpected false negatives or positives if your application or developers aren’t consistent with casing.
-
Most modern web applications treat URLs case-insensitively (especially front-end routes), so enabling this option should be a deliberate decision, not a default.
- The policy will generate two learning suggestions one for /faqs/ and one for /Faqs/ when case sensitivity is enabled
So why is the default enabled, when the modern front-ends are case insensitive ?
It is on by default because in the absence of information or understanding then this is the safe option, even though it is not required in most cases.
Example of MVC Controller Method
This is a typical MVC controller method using a "Route Attribute" to specify the URL that the method will respond to. Here it is /blogs/singleblog (this is not going to be case sensitive by default,
<Route("~/blogs/singleblog")>
<ActionName("SingleBlog")>
Function Blog() As ActionResult
End Function