ModSecurity is an extra layer of defense at your host to protect your site from having malicious code injected into it.
Despite that, some host support techs tell you to turn it off when you are having an issue adding code, javascript, or some plugin functions to your site.
Discover more about what ModSecurity is and why you need to keep it on at your host.
What is ModSecurity?
ModSecurity is on open source Web Application Firewall (WAF) that many hosts include in their server stack, meaning the software they use to run the server and/or make available to their hosting clients.
Most hosts running cPanel have ModSecurity installed and it can be accessed by the client in their control panel.
ModSecurity provides real-time application security monitoring and access control.
That means it is actively scanning incoming requests to your site for malicious code injections by a hacker.
Site owners who do not keep WordPress and plugins up-to-date are the #1 way sites get hacked due to these malicious code injections.
Even if you do keep your site up-to-date, plugins have security vulnerabilities every day – no kidding – about 15 new plugin issues are found every single day.
ModSecurity helps your host identify if any of these security holes are being taken advantage of.
It sends an alert to the host so they can take action on your behalf.
Why Site Owners are Told to Turn ModSecurity Off
Due to tightening of security across all WAFs made by different vendors, new errors are now showing up when site owners try to add new code like Google Analytics to the head section of their site.
When the site owner calls the host for help, far too often the tech support person tells the site owner to turn off ModSecurity – and leave it off.
As important as host security is in helping the host keep their uptime promise, why in the world would tech support tell site owners to turn ModSecurity off?
Simple.
The host wants to give the site owner an instant solution, not a process.
Chasing down the WAF rule that is tripping the security wire and causing the error is a process.
Here’s what is involved in that process:
- Hosts would need the site owner to cause the error and send them the time it occurred.
- That way the host can go into the server logs and see which rule got flagged.
- And then it’s a matter of checking which process in the code or plugin is tripping that wire.
- And then the host has to either whitelist that specific thing, or ask the plugin developer to fix it.
NOBODY is going to do all that!!!!!!
So, the host just tells the site owner to turn off ModSecurity in the control panel, or they do it for the client, and viola – fixed!
And because the host has no idea if the issue will crop back up if ModSecurity is turned back on, they simply advise leaving it off.
The Folly of Leaving ModSecurity Off
But, leaving ModSecurity permanently off removes the extra layer of security protection and the host is just shooting themselves, and their customer in the foot in the long run.
Now the host has zero way to detect when a customer’s site is under duress from an attack.
And the host has zero logs to check to see what the issue is and correct it.
Hence the site remains under attack and could be damaged.
Or worse, the malicious code could find its way through a backdoor on the site and impact the entire server and every site on it.
Attacks Happen Every Minute of Every Day
Bad bots trying to hack into sites never sleep.
Hacking to simply gather data on a site is big business – to the tune of multi-million dollars worth of business.
You may never know a bad bot has compromised your site without proper security to alert you or the host.
Most hackers aren’t interested in taking your site down.
It’s way more lucrative to slip in undetected and gather every email address from your database and sell them on the black market.
Those emails come from:
- WordPress user info
- Comments
- Form fields, like contact forms, if that data is set to be held in the database and not just emailed to the site owner. (See why I use Formidable Forms and turn off database collection of data for this reason.)
As Ryan Gray, CEO of NameHero Hosting says:
“If site owners could sit in my seat for a day and watch the sheer number of attacks that are attempted each day and mitigated thanks to ModSecurity, they’d have a much better understanding of how important it is.”
Why You Need All of the OWASP Protection You Can Get
OWASP (Open Web Application Security Project) is a global, not-for-profit agency that investigates and educates developers and business owners on internet vulnerabilities.
They are particularly interested in the types of attacks that are mentioned in this article.
ModSecurity and other WAFs, like the one in Cloudflare, follow the OWASP info closely and implement the monitoring and security measures they suggest.
ModSecurity implements security measures for at least the top 10 OWASP vulnerabilities. And that protection is free through your hosting provider, if they use ModSecurity.
The WAF in Cloudflare implements 25+ OWASP security measures. Those are available in the paid Pro plan, and I will not sleep without my money-making sites being on it.
$20/mo is a drop in the bucket compared to the damage done, and repair required, by a malicious bot attack without that protection.
(FYI, if you aren’t using Cloudflare, even the free version, you are missing all kinds of security and speed for your site!!! And I can help you set it up properly.)
Running Into New Security Tripwires
As hack attack vectors keep changing, and bad bot algorithms get smarter in running end around security measures, WAF vendors are constantly having to create new and better security measures.
That also means that they are scrutinizing all bots trying to access your site more closely too.
And that means even good bots are getting caught in that security net and causing errors.
We’re seeing this happen more often as the WordPress REST API is now handling more of those bot requests.
The REST API is an encrypted connection layer that WordPress uses to talk to the outside world.
Items that talk across that transport layer include checking the plugin repository for updates, and then delivering those updates.
It also includes the connection from WordPress to your computer when you are logged into your site.
The Gutenberg editor relies heavily on the REST API connection, and we are even seeing errors when site owners try to update their post when they have a good WAF running. To get around the issue, they have to whitelist their home internet IP address just to make a post.
Some plugins that are stringently following WordPress’ implementation protocol for connecting through the REST API are having the same issue. Site owners can’t make updates via their recipes or other special formatting plugins because of the tightened security.
And now we are even seeing the JavaScript in the Google Tag manager for adding analytics code to the site trip OWASP security wires.
There are tricks for getting around some of these ModSecurity issues.
But what we need is for WordPress to get in a room with OWASP and figure out what the trip wires are via the WP REST API.
It’s not like they don’t know it’s happening. There are multiple trac tickets open in the WP dev site over this.
And they are now noticing that the issues are becoming widespread and more frequent.
In the Meantime
We will have to work around the tightened OWASP security on every WAF our site goes through for now until WordPress fully addresses this issue.
Until then, don’t follow any advice for permanently turning off ModSecurity at your host.
You are putting both your site and the server it’s on at risk.
Find the security rule that is being triggered and deal with it at that level.
Or, see this post for how to turn off ModSecurity temporarily to get a Javascript code installed, like Google Analytics tracking
Leave a Reply