WordPress has a pretty poor reputation when it comes to security, so here are some WordPress security tips from Acunetix. The WordPress security perception is mostly unfounded sadly, as core WordPress is pretty secure – as long as it’s updated.
The same goes for plug-ins and themes, if poorly maintained they are an easy ingress for an attacker. The below guide can help you cover most of the main angles to protect your site and includes some fairly advanced tips too.
WordPress sites are notoriously lacking when it comes to security. Be it due to an insufficient security expertise of the developer, or the use of one of the many plugins available (of which the security cannot be guaranteed).
With WordPress running on 1 in 5 sites on the Internet, it is no surprise that they are a very popular target for both experienced hackers and script-kiddies alike. In 2013 around 90,000 WordPress sites were hijacked for use in a botnet. They are also a popular target for malware.
This is why we’ve taken some time to detail some measures which can be taken to address the basic security holes or malpractices that are commonly present in thousands of WordPress sites.
Check out the excellent and very thorough list of WordPress security tips here:
WordPress Security: Top tips to secure your WordPress Application
Vladimir Smitka says
I don’t find the article excellent… A lot of tips is very vague and had been mentioned in many articles before. Some of them may break some functionalities:
#7 breaks AJAX functionality – you should write an exception for admin-ajax.php
#11 may also break many things (it is mentioned in the article)
There are some other mistakes as well:
#9 there is a typo in RewriteCondition, so it can’t work – a backslash is mussing (d => \d)
I usually use this Cond (it protects you from crafted query with spaces/hexa encoding):
#10 “FORCE_SSL_LOGIN” is deprecated, I also recommend to use HTTPS everywhere
The reasons are also often inaccurate:
#8 I think the main reasons for disabling the file editor are:
prevention of breaking the site by its owner
to reduce impacts of XSS vulnerabilities
If an attacker gains admin access, he can upload his own plugins (you can disable it with DISALLOW_FILE_MODS, but it also breaks autoupdates…)
#6 there is no information about data in cookies – they are used for logging in -unique salt may prevent generation of “autologin” cookie by attacker (there are improvements since WP 4.0). These salts are also used for tokens in forms to prevent CSFR.
You can find many useful tips in official WP codex – http://codex.wordpress.org/Hardening_WordPress and you can check my WordCamp Prague 2015 presentation too.