A question we get a lot is, Why Isn’t WordPress more secure?
Excellent questions. We used to wonder this ourselves, when we got started!
A few reasons:
First, due to historical legacy reasons. WordPress was built the way it was built, using great technology of the time. PHP was the coolest thing ever! Perhaps today, it is easier to build a safer system from scratch, but it wasn’t when it was first developed. Technologies change, but software remains in the language it was written.
Secondly, there is a trade-off between “flexibility / easy of development” and “security.” Said differently: What makes WordPress so amazing is that it is sooooo easy to work with: you can quickly, trivially, change the source, change a design, add a widget — do almost anything. We love it because, it lets us make any changes we want without much effort. But with great power comes great responsibility: the ease of development has its cost, and that cost is in security (and performance – but that’s a topic for another day). To implement so many ideal security measures would slow down the core dev… and no one wants that. Well, “no one” except for us!
Third, shockingly, many of the security measure are controversial. Incredible to believe, I know! Take, for example, banning IP addresses that hit too many 404-s. Let me explain. A common tactic to break into a site is to just try lots and lots of URLs, that contain plugins with known vulnerabilities, to see if the user happens to have it or not. If they do — hack! If they don’t — a “file not found” (404) error. But there’s a downside to this: logging every 404, could bloat the database to be huge — thus slowing down the site. Plus, during stages like developing the site, the developers often to to URLs that may not exist — thus accidentally locking themselves out. (No, that’s never happened to me, no, never, and especially not two days ago, which served as the inspiration for this blog post — no, of course not, this is merely hypothetical.) As a result, the core WordPress development team has made a trade-off on purpose: lets leave WordPress with the minimum configurations possible, and then let each site administrator decide for himself which trade-off-s he/she’s willing to make. As a man who loves flexibility, I support this philosophy.
These are the three core reasons. Perhaps there are more, but it’s too early in the morning for me to think of now!
Any questions? Bueller, Bueller? Just ask!