I had a client come to me, completely at their wit’s end. Their site had been hacked for the third time in a month. They’d paid for those “emergency cleanup” services, installed a handful of security plugins, changed all their passwords. The works. But the hacker kept getting back in, usually by dropping a nasty little PHP file in the wp-uploads folder. Total mess. The actual problem wasn’t the specific plugin vulnerability they exploited; it was that the server’s file system let them write that file in the first place. This is a fundamental flaw in how most WordPress hosting is structured.
Why Traditional WordPress Security Is a Losing Game
On a standard server setup—even a good VPS—PHP needs permission to write to disk. It has to. That’s how you update plugins, themes, and how you upload media. But that very permission is the security hole. Hackers find one tiny crack, one outdated plugin, and they use it to write a file. Now they have a backdoor. My first thought, years ago, was to just lock down file permissions with chmod. And yeah, that helps, but it’s a nightmare for maintenance. You have to SSH in to update anything. The alternative is to pile on security plugins. They scan for malware and try to block bad requests, but they’re treating the symptom, not the cause. It’s a constant, reactive game of whack-a-mole, and it adds a ton of performance overhead.
Serverless Security: Start with a Read-Only System
This is where a serverless architecture changes everything. When your WordPress site runs on something like AWS Lambda, the code itself is deployed to an immutable, read-only environment. A hacker can exploit a vulnerability all they want, but they simply cannot write a file to your theme or plugin folder. That whole attack vector is just gone. It’s not patched over; it’s architecturally impossible.
On a traditional server, you’d add an Nginx rule like this to try and prevent PHP execution in your uploads folder. It’s a smart move, and you should do it.
# Block PHP execution in the uploads directory
location ~* /(?:uploads|files)/.*\.php$ {
deny all;
}But here’s the kicker: with a proper serverless setup, you don’t even need that. Your uploads directory isn’t on the same system that’s running PHP. It’s an object store, like AWS S3. An attacker can upload backdoor.php all day long. When a request comes in for that file, the system just serves the file for download. It never, ever passes it to the PHP interpreter to be executed. This is a fundamentally more secure model, a concept I first saw explained really well over at carlalexander.ca.
So, What’s the Point?
Serverless doesn’t magically fix everything. You still need to use strong passwords and write secure code to prevent SQL injection. But it eliminates the single most common and destructive type of WordPress hack. Trust me on this.
- Traditional hosting tries to patch a writable file system to make it secure.
- Serverless hosting is secure by default because the core file system is read-only.
- This completely removes the threat of hackers uploading backdoors and malware.
Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to be built on a solid, secure foundation, drop my team a line. We’ve probably seen your exact problem before.
When your site’s security model relies on hoping a plugin catches an attack, you’ve already lost. An architecture that prevents the attack from succeeding in the first place is the only way to go.
Leave a Reply