A user posts a comment, and instead of actually posting the comment, gets redirected to the main page of your website. Not just annoying for webmasters, but a very unpleasant experience for visitors that like to actively contribute.

Quite often, with WordPress, this is caused by a false-positive being triggered by mod_security.

In this short article, I’ll show you what might be causing this issue, how to identify it, and how we can fix it.

WordPress, Mod_Security and False Positives

The task of mod_security is to catch dangerous and malicious “code” that might harm your web-server.
One of the most common ones being “SQL injection“, a technique where the “attacker” adds certain characters to submitted comments or posts, which will make the SQL statement (database) that stores the post or comment, do something really bad to your database or data.

Obviously we do not want this to happen, so mod_security does a great job in trying to catch those “injections”.

However, it can be very difficult to define a rule that catches everything 100% correct, which causes these false-positives. A perfectly legit text get’s flagged and mod_security takes the safe route and brings the user back to your homepage instead of executing the SQL statement to store the “malicious” post.

Mod_security has all kinds of rules defined to catch all kinds of malicious attacks, so it’s not just one rule. But one of these rules that seem to fire quite often, producing a false-positive, is rule “300016” with the message “Generic SQL injection protection”.

You can check this on your server by checking the mod_security log file.
On my server it’s located at: /etc/httpd/logs/modsec_audit.log or /etc/httpd/logs/error.log

When accessing your server from a shell or using SSH, a simple “tail” statement right after posting an offending comment, will reveal this. Something like this:

If you see messages like this (I’ve added a few line-breaks), then this article is for you … well, unless you know for a fact that the link uri "/wp-comments-post.php" is not legit, or if the rule id and message point to another issue of course.

Disabling a mod_security rule for WordPress

One option is to completely disable this rule, but by doing so we expose our web-server to an unnecessarily high risk. So I really consider that a very bad plan.

It’s a much better idea to disable certain rules only for very particular pages.

Besides that … WordPress has functions build in to sanitize posted comments, so we could disable this rule just for the places where users post comments and WordPress actually screens and cleans the posted data.

Knowing all that we can relatively safely create a list, in which we “whitelist” certain rules for certain links in our WordPress setup.
I do however strongly recommend to leave this to as little exceptions as possible of course – the less exceptions, the safer for our web-server.

Shared/Virtual Web-Servers

It can be that your website is running on a shared server or a virtual web-server.
In a situation like that, you will most likely not be able to modify the whitelist as it might affect other websites on that same server as well.

In that case you will have to contact the support team of your web-host provider.

Root access Required!

To edit your mod_security config file (whitelist in this case), in general ROOT ACCESS will be REQUIRED.

The whitelist can be found in one of two files, either called whitelist.conf or exclude.conf .

Before we can create a whitelist, we will need to find or determine which rule(s) cause the false positive(s). I found that, on my setup, the most common ones were: 300013, 300015, 300016 and 300017. With 300013 being the most common one!

Naturally this all depends on the type of website you have and what kind of text visitors will or might enter.

The whitelist.conf (or exclude.conf) file can be edited with a regular text editor like “vi” or “nano”:

cd/usr/local/apache/conf/modsec2/nano whitelist.conf

The file might already contain one or the other exception, and it’s probably good not to touch those – just add exceptions, do not remove them unless you know why they are there or if you placed them yourself..

The sequence in which you add these to your whitelist does not seem to matter (correct me if I’m wrong!).

Disabling a mod_security rule for bbPress

Now I have found that bbPress can have it’s own issues, since the URL you’d like to use might not be consistent (changes per forum and forum-topic).
In that case we need to use a regular expression to catch these.

The problem is that the URL is (for this forum topic only): /forum/development/sql/
For another topic this could be: /forum/development/delphi/ or /forum/development/lazarus/

So we’d have to make a rule for each of those? No we don’t,… thank goodness.
We can solve this with a regular expression (well almost anyway), say we’d like to disable to rules for all URL’s that start with “/forum/development/”:

Restarting Apache

Once you’ve saved your changes (in nano: CTRL+X, Y, press ENTER), you will need to restart Apache so it takes the whitelist in consideration.

Restarting can be done in several ways. I usually do this through cPanel’s WHM (Web Host Manager).
Alternatively, depending on your setup, this can be done with one of these methods, where root access is typically needed,

Alternative Whitelists for WordPress

Obviously I have been searching the web for all kinds of solutions.
For example, this article at WPSecure is a very good read as well …
Since they could be of use to you, I’ve posted a 2 examples below – I have not used or tested these, so your milage may vary.

Again; only pick those exceptions you really need. Less is better.
And … don’t forget to pay attention to the “LocationMatch” line, as they will tell you when the exception is being applied so you can determine if this is needed for your setup or not.

Donation options

Donations are very much appreciated, but not required. Donations will be used for web-hosting expenses, project hardware or a motivational boost (a drink or snack). Thank you very much for those have donated already! It's truly AwEsOmE to see that folks like our articles and small applications.

very nice article. I am still fighting with modsecurity. Do you have absolutly no false positive comments with your configuration? I always think: “yes, solved” – but unfortunatly there are still comments blocked. Especially when they use special character.

thank you very much – as you migth have guessed … modsecurity is something we need, but it’s not 100% perfect and certain scenarios will still cause problems. Having said that: after applying these rules, I have not experienced issues on my website or the forum. This however is by no means a guarantee that this would be the case on your website. I guess it depends on what kind of false positives you’re getting.

Well, since you’re sure mod_security2 is running and you’re using Easy Apache 4, then this might be a good read.SWorking with modsec2.user.conf would probably be the recommended way to make your own rules indeed.