Anything you add beyond that is on you, and you should be vetting your vendors or own code properly.
I have to wonder what your purpose for attack here is. Are you developing a competing product?
The main use for WAFs that I consider valid is emergency response to recently discovered vulnerabilities while a patch is being discovered and applied.
The other use case is external rate limiting and DoS protection. But most often it is better to do that in the app anyways.
- Can section off certain requests
- Can rate limit
- Can catch basic injection attacks
With the wafs that integrate with WP such as wordfence they can also do things like:
- Check for bad file permissions
- Check for bad web server configuration
- Recieve ruleset updates for zero days that are actually threat surface specific
Having a WAF in place that is threat surface specific isn't as much about saying "its not needed if the code is good" as much as it is saying "the code might not always be good. We are not perfect. I'm at least going to have an extra layer or two of defence to try and stay safe(r) and give me some breathing room between an exploit and a patch".
As long as you have WP updated, and a good configuration with your stack (PHP, MySQL, Nginx) it's hard to hack.
The main vulnerabilities come from 3rd party plugins and themes, and shared hosting with older versions of the stack. It's like faulting windows for vulnerabilities in an external .exe app.
If you use the default setup, and follow security guidelines, you should be ok.
If security is a concern you can simply avoid third party plugins and themes, or limit your use of them to reputable vendors who have good track records.
The code of WordPress itself is pretty robust and the Core team has a great history of fixing vulnerabilities quickly.
It is not for every use case. I think some of the new static site generators are great, but WP fits the bill, when we need a fairly dynamic, configurable, maintainable, site.
The “security issues” are, IMNSHO, a reflection of the much wider “depenecapocalypse,” that is plaguing the entire software development industry, where lightly-trained, and inexperienced, devs, slap all kinds of executables into their projects, with hardly a glance at the bona fides of said executables, which, in my experience, can be … questionable.
I admit that I have created “Frankensites,” by using too many plugins (in fact, today, I am about to rewrite one, using as "bare bones" an architecture, as possible). Even good plugins can have a limited shelf life, and I have learned (the hard way) that paying for extensions and themes buys me almost nothing. I have been aghast, when examining the code, in some of these.
There’s a lot of crap WP code, out there, but I have been fairly impressed with the quality of the code and architecture of the core system.
The one thing that I think needs improvement, is the WordPress Codex. It’s a mess. I’m often better served, examining the code directly, than relying on that.
I don't do Web sites as a living. There's millions of better Web developers than me. I like to be able to walk away from a site, and let it stand on its own. WP has served me well, for that.
The original Codex can be considered obsolete as it has been replaced by developers.wordpress.org which is much more informative and up to date.
It could be fine if you put the admin portal behind a firewall but I would also recommend moving forward and stop developing new websites using Wordpress if you care about security. And you should probably care about security.
If the server is the target, it either still has access to it, or to some alternative computer which, for a private individual writing a blog, will be their much more valuable personal device.
Yes, you can spin up a VM, generate html, run it through all sorts of tests and only then upload it. The victims of this hack aren’t going to do that.
Tell your web server to only serve the login stuff to you (certificates, HTTP Basic Auth, whatever). Problem solved.
And what is your solution?
A SSG also generates something and could embed bad stuff.
Something has to upload your SSG generated files and thus needs access to your web server. If you're running it on your personal device it could compromise it.
Really, stop trying so hard to invent Wordpress problems. If you don't like it, nobody forces you to use it.
Look it up, you're routing everything to static files in file system directories.
Only if you are requesting an URL (however "you" are identified) the webserver even contemplates serving something else.
It's an explicit rule for the special case. Everyone else doesn't see a PHP-FPM execution path at all.
My personal blog uses one of the default themes, I hosted extremely cheap, I NEVER touch it because it is autoupdated and it just works.
I did not review WordPress code so I can't tell how secure it is, but using this article to do a lazzy hit on WordPress is pathetic, this issue is as related with WordPress as you installing an .exe fom a random website is a Windows issue.
tl;dr: Use a static site generator.
The biggest reason is that its pages are not statically generated and allows for code execution when they contain no dynamic content.
The second biggest reason is the marketplace for plugins and themes; even if WordPress security audited their entire standard release, every single theme or plugin you install could compromise your installation. You’d think of a theme as something that provides colors and spacing, but they’re fully executable programs.
WordPress is conveniently written in PHP, which attracts inexperienced programmers with no understanding of web security.
The attack that OP links to is a supply-chain attack made possible by WordPress’es software architecture, but it could have happened on most more secure alternatives if they were equally popular.
So while it’s easy to ridicule WordPress for having no security and a poor architecture to withstand most attacks, we mustn’t forget that it’s a combination of its huge popularity and the ease of use caused by its simplistic choices that has lead to this breach.
Is there a proof for that?
A better assessment is that WordPress has made trade-offs regarding security, as anybody in the real world must. Individuals must also make their own trade-offs, including whether to run WordPress at all, then how to configure it and which third-party code to use. Sometimes we get the trade-offs wrong, and that should affect how people make future decisions.
Most People that use WordPress are not develoeprs or technical people. Find similar product with a WYSIWYG GUI , theme , plugins, cheap hosting, no bullshit licensing or breaking backwards compatibility and promote it to people or whoever hosts this blogs.
I think you are suggesting someone to replace his IDE with notepad since you can build application with notepad and gcc directly.
Wordpress has only one entrypoint and only needs to write to its data directory, so it's quite decent.
The big issue with wordpress is with the vast plugin system, where all bets may be off depending on what you run.
even whitehouse.gov uses WordPress: https://wordpress.org/showcase/the-white-house/