I have encountered many discussions regarding WordPress and it’s security. I love arguments and I believe we should stop see everything in black and white. Hence my title. It can be secure. Because I believe it can also be insecure, but more importantly I want to share my knowledge on the topics regarding security. To make it more secure.
I have managed over 150 WordPress websites professionally on my previous job(s) and this website itself is WordPress too. Over a timespan of roughly 3-4 years, I have had 0 breaches. One could argue: but you got “pwned” yet you did not notice it. Ok so, please bear in mind that when you develop websites and you have 150 clients, there are some really eager clients. They will notice everything. I have had clients arguing that their TTFB (time to first byte) was 5ms faster 2 weeks ago. They will notice a hack ;). Other than that, I did have logging and metrics and my “cloud provider” was always spot-on when it came to network monitoring (they would call me within an hour if something was off…).
So let’s talk arguments.
“WordPress is too popular, which makes it a huge target.”
Perhaps followed by – “My custom CMS is safer”
First one: true. Second one: haha. ok.
So yes, you are a bigger target because you use WordPress, but being a bigger target says nothing about being more secure. It just states that you are being targetted more often. Which is fine, as you can prevent attacks. Let’s make a stupid comparison:
- Safe website: 100000 times attacked, 0 breaches
- Unsafe website: 1 time attacked, 1 breach
Congratulations on your unpopular/less used CMS?
The power of a popular CMS is that in most cases there is an active community and/or company behind it. They really want to protect their brand and identity. Often this will result in a lot of pen-tests by people active in the community. It’s good for your name to find a huge flaw in WordPress. So this gets reported, patched and the whitehat hacker is “famous”;).
WordPress is able to patch security updates by itself without any user interference. This makes sure you are sound and safe without having to worry that much. I will get back to this later, as it is also a disadvantage.
Back to that custom CMS you developed yourself. We can use that community argument again. Perhaps thousands if not many more hours are spend by the community, testing, hacking and whatnot. How can you compete with such level of “testing” versus something you think that is secure? So your source code is not opensource, which is security through obscurity, yet it is still a false statement of security. I often have zero access to a source, yet I’m able to find flaws. A lot of them too. The source code makes it only easier.
Many WordPress websites are hacked
Semi-true. I mean, fill in some random other CMS or even your own for WordPress. Leave it online for 4 years without patching. What will be odds that such a website is hacked too? I have no actual facts, which sort of sucks, so please bear with me: In my opinion, 99% of those hacked websites are caused by:
- using illegal themes with backdoors
- illegal – means a premium theme that someone “found” online
- using plugins that have not been updated for over 2 years
- using themes that have not been updated for over 2 years
- ignoring every available update for your plugins or waiting for it for over a half year
- ignoring WordPress core updates
- insecure passwords*** – not entirely your fault, will get back on this later
Out of the box
I have to admit, there are some security related issues within the core of WordPress. I do believe some “leading parts” in the community are ignorant regarding various issues which are simply not getting resolved because of whatever reason. Perhaps technical debt or some weird technical vision/roadmap.
There are also some debatable features which cause WordPress to be insecure by default. This is fixable, hence my blog post, yet it is still something to keep in mind.
By default, it is possible to gain information regarding users, backend users and for instance the plugins you are running. Simply by accessing the WordPress JSON API : /wp-json/wp/v2/
Again, one could argue that some of this information is already visible/accessible. Yet let’s be honest; why provide an API to give so much useful information to potential attackers?
Lack of basic security principles
Was it so hard to implement a rate-limit on the login page? Or recaptcha? A default WordPress website can be brute-forced. Combine this with the “free” intel on the user accounts via the API it’s becoming more easier. I’ve seen these “changes” in Magento, where for a lot of forms you can enable native recaptcha, out of the box.
I have investigated multiple plugins and I have unfortunately checked the WordPress Core. To be honest it is often just spaghetti code. With the way WordPress works, plugins are made in a terrible way. I cannot blame the makers of such plugins but this just makes it easier to make mistakes, resulting in more potential security flaws.
However, I notice that things are somewhat changing by writing more mature code, yet it will never be a great OO MVC base, just because of how WordPress is. I do however believe a lot of people are aware of this, which results in new technical “features”, frameworks, core changes. We will see in a few years how the core has changed.
I said I would come back to this topic. Eventually it is debatable. One argues that having automatic security updates is great, because it will patch so many installations when it is really required. Especially when some users hardly upgrade. While you can also argue that is is a huge security risk having a “way in” towards millions of installations. If that system is compromised, we will have the biggest shit storm ever happened in the IT world.
How to make it more secure
Mitigate known/common issues
- Block the API for non-authorised users
- Enforce long & secure passwords for your users and admins
- Add a feature to limit brute forcing on your login page – For instance a rate limit on your account, IP whitelist, recaptcha, etc.
These are just a few simple things you can do with ease. If we have taken the fact of a clean WordPress install, you will have a pretty solid base which, if you keep updating everything, will be pretty solid:
- I really hate to say “impossible” but it’s really hard to brute force a admin login
- The core is up-to-date, as long as there are no 0days, there is no real chance of getting in
- We have used “proven technologies”, no dodgy plugins and/or themes which might cause issues
If you want to be secure, you need to be in control. This means you have to gain knowledge of what the fuck you are doing. Nearly anyone can install/host/manage WordPress, which does not mean you should.
There is some vital background information required in your choices of plugins, themes. I got my experience by having checked the source of every plugin I use(d). I follow security bulletins on plugins, knowing which plugins have had major issues in the past. This makes it easier to be in control of what plugins I want, or actually, do not want.
Patch when you can patch. Basically, you should patch/upgrade the moment an update is available. We can alter the update cycle if you have the knowledge of the changes; does it contain a security fix? If not, you can wait for your regular update cycle.
Pick your 3rd parties
Don’t just install anything. If you are really keen about security, you should actually read the source code of a plugin and/or theme. General speaking; it is fairly ok to install a plugin used by many, which is updated regular. Yet always keep in mind: you are using “some” code, which, unless you check it, may contain some weird stuff.
Hosting and serving
When hosting WordPress there are so many options which can mitigate a lot of issues. If we take the statement of: “we are going to get hacked” we can prevent so many things if that actually happens.
- Do not allow executable rights on certain directories. For example; do not allow PHP files in the upload folder(s). This mean if you get hacked, someone uploads a malicious file, it cannot be executed. Yes, you did got hacked, but nothing was exploited. A huge difference
- With above, executable rights are just one part. We can tell Apache or Nginx to ignore certain files in certain directories.
<Directory "/home/*/www/uploads"> AllowOverride None SetHandler none SetHandler default-handler Options -ExecCGI RemoveHandler .cgi .php .php3 .php4 .php5 .php7 .phtml .pl .py .pyc .pyo <Files *> SetHandler none SetHandler default-handler Options -ExecCGI RemoveHandler .cgi .php .php3 .php4 .php5 .php7 .phtml .pl .py .pyc .pyo </Files> </Directory>
We can also whitelist the admin area for a certain IP. Simply speaking, we just firewall the backend for your own IP address. This makes it more secure on 2 parts:
- People cannot brute force, nor even login even if they have phished your credentials
- If there is a 0day, the backend cannot be abused because it is firewall’d.
Limiting, rates and WAF
There are so many tools to prevent and stop attacks. These are “helpers”, in general they should reduce load and bad requests. They are not THE way to make your application secure and solid. Merely they provide insights, metrics and will stop hammering requests on your website.
There are tools such as mod_evasive and fail2ban which have certain “rules” they will apply on your logs. If certain events trigger, they will ban an IP. Please do keep in mind that if someone is brute forcing, it is not hard to use a proxy. Hence again my note on that it should be helpers, not core security 😉
There are also multiple WAF solutions. I guess the easiest one is from Cloudflare which is the easiest on the implementation. Given that you want to use Cloudflare in the first place.
When you got everything running, it’s again so important to maintain it. You want insights on performance, on what files there changed, on what pages get hit including their page query. Without these metrics, you are still in the dark whether your application is still secure. Be in control. Be knowledgable.
There are again many tools which can support you in this. Tools that make hashes of files to know if a file is changed on runtime. If you run in containers, you could also just make files read-only. If you have made a change, push a new image. Yet then it is important to get access to logs, logs that provide information that “something tried to alter file X”.
And the conclusion
It is all about how you deal with an application. If you neglect something, you will have a bad time eventually. No matter what application if you have, it is always vital to have knowledge of its internals. Just as it is always vital to have a good synergy between “hosting/managing” and developing an application. They can both make each other much stronger and better.
So no, WordPress is not insecure. Nor it is secure. Yet nothing is. Let’s talk arguments first and find out why things are happening. Then try to fix those things. If we do that, we have a chance to make something that can be secure.