Table of Contents
- 1| Configuring Mod Security for parsing request response body
- 2| Optimizing performance while parsing response body
- 3| Some frequent pitfalls while parsing response body
- 4| Finally if you still have some issues
Sooner or later, people decide that they need to parse response body in order to detect or prevent some malicious activity. Web application firewalls are useful for exactly the same goal.
Whenever it comes to WAF, Mod security is the DIY tool for many people. It has nice integration for parsing response body, but there are some pitfalls you better consider.
1| Configuring Mod Security for parsing request response body
You need to add the following directives in Apache configuration file, in order to tell mod security – parse the response body:
Setting SecResponseBodyAccess is enough for making this work, but there are some more things, which will guarantee you good performance + parsing what you need and behaving the way you like
2| Optimizing performance while parsing response body
We have successfully enabled response body parsing, but in a real world that’s far from enough.
Parsing response body on a high traffic site, could lead to enormous performance issues.
I suggest considering the following options in order to make sure, you get the best performance while parsing the body.
- Setting SecResponseBodyLimit to a reasonable size
By default SecResponseBodyLimit is set to 512KB, which not always is what you need. If your mod security rule must parse only responses, which are to say 5-10KB in size (or anyting less then 512KB), it would be better to lower SecResponseBodyLimit as much as you can.
- Setting SecResponseBodyMimeType to parse only types you really need
By default SecResponseBodyMimeType is set to “text/plain text/html”, but do you really need them ?
Well that answer is “it depends on your case“. If your response body parsing rule is going to process only requests returning “text/html” Content-Type, then there is no reason to add additional overhead by also parsing “text/plain”.
It is good practice to shorten the Content-Types only to these you may need for parsing.
If you for example need to parse ONLY requests which reponse’s Content-Type is “text/xml”, then you better add the following snippet to your configuration:
When you change the SecResponseBodyMimeType, always make sure to issue “SecResponseBodyMimeTypesClear” in order to make a clean start.
3| Some frequent pitfalls while parsing response body
Your http request is being dropped because of ResponseBody exceeding your SecResponseBodyLimit limit
By default mod security is configured to REJECT requests, which has response body bigger then the limit defined. This could lead to some hard for debug problems or bad user experience.
If your reponse body parsing is not MISSION CRITICAL and you are okay to let it pass in case it’s bigger size, then you MUST set the following option:
This way, whenever your response body exceeds, it just won’t be parsed by mod_security, and let pass successfully to the client.
Your newly created response body parsing rules are not working
Sadly, I went through this also.
Whenever you add new response body parsing rules, make sure to revise your settings for the following directives:
There is a very big chance, that your new rule has some more requirement about these directives, which are not satisfied and this is causing it to not work as expected.
For example you may need to add some additional MimeType for parsing, or to increase your response body size limit.
4| Finally if you still have some issues
If you have any struggles or misunderstandings, the manual is your friend:
And also don’t forget the mod security user mailing list, where you can subscribe from here: