We don’t use security plugins on WordPress sites. Here’s what we do instead.

WordPress is a wonderful CMS but its dynamic and Open-Source nature means site owners often suffer from slow and vulnerable sites. As a result, WordPress site owners typically have to add a slew of plugins and tools to optimize their site for speed and security.

The problem is that these band-aids that keep the site from falling apart can come with some not-so-lovely side effects. Much like drug commercials with the dramatic scrolling list of side-effects.

Security plugins may cause bloating…

One of the most popular WordPress security plugins is Wordfence with over 2 million downloads. WordFence has contributed tremendously to the security of the WordPress community, both in terms of what the plugin offers, but also in terms of ongoing research and reporting.

Wordfence is very robust and has many options, and settings, but site owners usually just leave all the default settings when adding the plugin to their site. The default settings do offer a good level of protection, but they can end up causing strain on your server, which could cause your site to slow down, or cause other functionality on your site to stop working properly.

For example, Wordfence offers malware scans which can take a lot of time to execute and can use a lot of server resources.

Wordfence also has a feature to stop brute-force attacks. In order to do that, the plugin needs to keep a log of who is attempting to enter the site, where they’re coming from, and how many times they attempt to login. This active logging can bloat your database and add extra load on the server.

At Strattic, we don’t use security plugins

TL;DR: Strattic users serve a static version of their WordPress site. Having a static site removes 99.99999% of the attack surface.

Here’s how Strattic works in a nutshell:

Let’s take a look at some of the most common WordPress vulnerabilities and how they’re handled on Strattic without a plugin.

Cross-site scripting (XSS)

This is the number one security vulnerability in WordPress sites.

Cross-site scripting (XSS) is when a hacker tries to inject a script into your source code and have it loaded in the browser. It can originate on the server or client side. Once the attacker has this type of privilege it has the same privilege as your browser so it has access to your cookies, your web storage, and your DOM, which is not good.

A recent example of a XSS attack is the Browsealoud attack. Browsealoud is an accessibility browser add-on. The attackers got access to the library that these sites were calling and turned it into a cryptomining tool and 5,000 sites were affected.

Solution
By removing the database and serving a static site, Strattic eliminates any server-side XSS attacks.

In addition, Strattic allows you to set Content Security Policy (CSP) in order to whitelist resources that you want the browser to load for your webpage. Rather than trying to guess what potential harmful resources are out there, you authorize trusted services.

A CSP is added to the header and tells the browser which scripts are ok to load, and which aren’t. For example, you might create a CSP that authorizes the browser to load Google scripts like Google Analytics tracking code.

The point of CSP is not to prevent XSS attacks, but it gives your site an extra layer of protection if your site is compromised.

You can read more about CSP here.

DDoS or Traffic spikes

A distributed denial of service (DDoS) attacks work by overwhelming a server with data requests, with the intention of bringing down the server or the site.

You can take a look at some of the notable DDoS attacks that made headlines in 2017.

Traffic spikes, which could happen if your site gets featured on the front page of a popular publication, will likely overload the resources on the server with the sudden shock of thousands of visitors. In a way, this can be seen as a mild form of a DDoS attack insofar as the server is getting majorly overloaded and doesn’t have the resources to keep up, which could result in your site going down.

Solution
Strattic sites are static and disconnected from the WordPress installation, so they can scale almost infinitely.

In addition, Strattic uses serverless architecture which runs only when triggered by an event, like a new visitor to the website so that you don’t need to worry about scaling or traffic spikes, because it is inherently elastic and you’d never need to add more server resources ahead of huge press coverage.

Finally, Strattic uses an integrated CDN to serve the static web pages from a location closest to the user. So, if one CDN location gets DDoSed, another location can take over and avoid any downtime at all.

SQL injection

The second most common vulnerability on WordPress sites is SQL injection. An SQL injection is when a hacker injects SQL commands into a submittable form on your site (ex. comments form, contact form, search form, etc), in order to get access to your site’s database. This vulnerability is usually a result of poorly-coded websites, plugins, or themes.

Solution
Since our public-facing sites are static and detached from the WordPress installation, there isn’t a database connected to the site’s forms. Strattic has client-side functions that handle forms instead.

Brute force attacks

This is the cyber equivalent of someone coming to your door and trying to break in with an infinite amount of keys to pick the lock.

For a WordPress site, a brute force attack refers to a hacker (usually a bot) relentlessly trying to break into the backend of the website with trial and error using an infinite number of username and password combinations.

Solution
Since Strattic’s public-facing static sites are detached from the WordPress installation, there’s nothing to log in to, and therefore nothing to hack.

Man-in-the-middle Attack

In order to make sure that all visitors are reaching the https version of your site, web developers will generally set up 301 redirects from the http version to the https version for those users who type in the http link, or are following links from other sources that still point to the http version of the URL.

However, what many people don’t realize is that the redirect does not fully protect the site visitor, since there is a window of opportunity (however small) between when the visitor requests the http version of the site and when it reaches the https destination for a type of attack called a “man in the middle” attack. Some examples of these types of attacks are protocol downgrade attacks and cookie hijacking.

Solution
A security header called the HTTP Strict Transport Security (HSTS) header, allows site owners to instruct browsers to always go straight to the https version. This removes the window for the man-in-the-middle attacker since the http version of the site is never accessed, not even for a second.

Because security is extremely important to us, we have implemented HSTS for all our client’s websites. In order to complete the process, all our clients have to do is fill out the HSTS Preload form to get added to it. You can learn more about HSTS here.

To sum up…

To sum up, here’s a comparison of standard security measures versus how they’re handled on Strattic.