Anyone who manages WordPress sites knows how critical it is to keep them secure. Every day thousands of sites get hacked. The consequence of that are often disastrous. They range from lost income to Google blacklisting the WordPress site.

WordPress itself has always been very secure. But we never use WordPress in a vacuum. We install themes and plugins. We need to host the WordPress site somewhere. All these are potential attack vectors that someone can use to hack your WordPress site.

Because of its nature, serverless PHP makes a lot of these attack vectors irrelevant. This is another reason why it can be a great way to host a WordPress site. (Besides the ridiculous scaling potential.) It doesn't matter whether you're using Ymir or not.

But how can serverless PHP can help keep your WordPress site secure? Well, the best way to understand is by going over serverless PHP architectural elements and how they affect these attack vectors.

Code deployed to serverless PHP is essentially read only

With serverless PHP, you can scale from 0 to thousands of connections in a minute. To do that, AWS Lambda and other similar services will always use the same code that you deployed with. And that code will always be read-only on the server that executes it.

This means that all vectors that rely on injecting PHP files into your WordPress installation don't work. We're talking injecting code in your themes, plugins, wp-config file, includes directory, etc. Those are all impossible because a Lambda function is read-only.

The only folder that isn't read only is /tmp. But even if someone injected files there, they wouldn’t be able to stick. That's because a Lambda function is ephemeral. It can exist one minute and be gone the next. Not to mention that it's only injected in one of hundreds of Lambda functions that could be running concurrently.

But for a code injection attacks to work, they need the code to actually stick to the server. And by its nature, serverless PHP doesn't allow this. This is why this whole category of attack vectors is a non-issue with serverless PHP.

It's also worth noting that this also means that the plugin and theme file editors won't work. This is also another common attack vector for injecting PHP code into your WordPress site.

Your uploads directory isn't on a server

Another common place for attackers to inject files is the uploads directory. You upload a file to it. And then you can just have PHP execute it by making a request to it.

That's why it's a common security practice to disallow PHP file execution in the uploads directory. That way, if someone injects a PHP file and requests it, they'll just download the file instead of having PHP execute it. With serverless WordPress, this is the only possible behaviour because your upload directory isn't on a server. It's on S3.

Above is a diagram of the serverless WordPress architecture. (To read more on it, check out this article.) As you can see, CloudFront sends all upload file requests to S3. They never make it to the PHP runtime that runs the PHP code.

Instead, when they make a request to that PHP file, CloudFront will just send the PHP file back. Exactly like if you requested a text file. This makes it impossible for an attacker to remotely execute a PHP file in the uploads directory.

Things that can still happen to you

Serverless only really protects you from attacks that target the file system. So while serverless will remove these common attack vectors, there are still things that you should be wary about.

SQL injection attacks

SQL injection is still something you have to worry about. If you have a plugin or theme with such a vulnerability, you can still get attacked that way. The best way to prevent attacks like these is to just follow standard security best practices.

• Always keep your plugins and themes up to date.
• Always download them from trusted sources.
• Delete plugins and themes that you aren't using.

Brute-force attacks

Brute-force attacks can also still happen to you even if you use serverless. Much like with SQL injection attacks, you can protect yourself against these attacks by following security best practices.

• Don't use the default "admin" username.
• Use a two-factor authentication plugin. (There are a lot of them! This site uses Google Authenticator.)
• Use a strong and uncompromised password. (I built a simple plugin that helps with this.)
• Disable XML-RPC. (If you're doing everything else, this isn't as much of a problem.)

Denial-of-service attacks (DDOS)

In a similar vein as brute force attacks, you also have denial-of-service attacks (DDOS). This is something you can prevent using a web application firewall (WAF). Security plugins often come with a WAF or offer one as an external service.

If you're using Ymir or just running WordPress yourself on AWS, you can use AWS WAF. This is a full featured WAF with a lot of customizable options. That said, it also comes with a lot of pre-configured rules to help block known threats such as bots. But it also has a WordPress rule to block known vulnerabilities such as XML-RPC.

Ymir uses CloudFront to do page caching. If you also use CloudFront this way, you get some DDOS protection for free through AWS Shield. This will protect you against infrastructure layer attacks, but not application layers. (Also known as layer 7.) To protect against those, you need a WAF.

Worry-free WordPress security

None of what we just saw is exclusive to serverless. You can do all the things that serverless helps with using a regular server. You just need to either have access to it to configure it properly or use a WordPress host that uses security best practices.

The same goes with serverless and security plugins. There's nothing serverless does which you can't do with a security plugin. That said, security plugins are often a heavy-handed solution to security issues. They can often slow down your WordPress site significantly and cause other issues. With serverless, there's no performance impact to having a secure WordPress site.

And this is pretty much the benefit of serverless security. It's not better than what you can do yourself with a properly configured server and a security plugin. It's just a more worry-free way to keep a WordPress site secure. And there's something to be said to having that peace of mind.