What the hell is “snake oil”? Let’s take a look at the definition of the term in Wikipedia:
Snakeoil is the derisive name for a product that has little or no real function but is marketed as a miracle cure to solve many problems.
If you look at many guides, most of them fall far too short. Unfortunately, installing a security plug-in or setting individual parameters is not enough. Methods such as securing the login via Logging Atempt Limits are also absolutely useless. These block a single IP address if it logs in incorrectly too often. However, hackers do not attack WordPress systems with a system, but by means of botnets – every login comes from a different address and this mechanism comes to nothing! Security plugins do not offer any real security either. Although these can help to a certain extent by warding off simple attacks, they are at most a supplement to the really important measures. Real WordPress security is based on numerous individual building blocks!
In this article, I would like to present my strategy on the topic of security in WordPress.
It’s best to take a look at how most break-ins on WordPress sites happen – the most common reasons are:
- Too weak passwords in admin / user accounts
- Outdated WordPress, theme or plugin versions
- WordPress files accessible from outside
- SQL injection (e.g. via forms)
- Brute force attacks on the WordPress login
- Brute force attacks on the XMLRPC interface
Let’s take a look at how these problems can be addressed, or how I deal with them.
- Administrative access and passwords / brute force attacks on the login area
The most important protection of all is that of the WordPress login area! In general, I do not grant administration rights to customers unless it is technically impossible to do otherwise. In addition to the requirement for long passwords, every admin access is secured with at least mandatory 2-factor authentication[1]. I use the WebAuthn plugin for all new websites that do not require normal visitors to log in (e.g. store systems or forums) and configure it so that login is only possible with a passkey[2]. Furthermore, the login URL is set to a different path for these systems. Although the latter only marginally increases security, it is a valid component for securing the login, even if it does not really stop an experienced hacker.
In addition, I prevent scanning for user names within pages and posts by means of corresponding .htaccess directives. - Outdated WordPress components
It is important to keep the WordPress components (in addition to the WordPress core system, especially the plugins and themes) up to date. I do this via an automatic update function that is set for all components, but also manually if there is an urgent need for an update. The latter always occurs when a security vulnerability becomes known, so you don’t want to wait for the automatic update to carry it out at some point. Notification of such a critical security vulnerability is achieved on the one hand by alerting the Ninja Firewall security plug-in used, but also by tracking relevant sources on the Internet. In this case, manual installation is carried out centrally via the MainWP[3] console. - WordPress files accessible from outside
It is important to protect special files and directories from external access. To do this, these are protected in the .htaccess file[4] using special directives. - SQL injections
To avoid SQL injections, care should be taken first and foremost to use only known, solid and well-maintained plugins. I use special directives in the .htaccess file for further protection. - Disabling the XMLRPC interface
The WordPress XMLRPC interface is a well-known gateway in WordPress. The XML-RPC was developed to standardize communication between different systems. Applications outside of WordPress, such as blogging platforms and desktop clients, can thus exchange data with WordPress. In the meantime, this has been replaced by a Rest API and is therefore completely deactivated for me
In addition to the security measures mentioned above, further security measures are taken, such as the setting of HTTP security headers and special security measures within the .htaccess file.
Conclusion: There is no such thing as 100% protection against successful attacks, but you can do a lot to make it less easy for hackers by taking appropriate measures!
