Schurq

7 myths about WordPress security

|
Reading time minutes
By Patrick Schokker

7 myths about WordPress security

 

WordPress is incredibly popular. Many WordPress users online share their experience with the platform. Online security is a hot-topic here. Which, of course, is also a very important topic. After all, website owners want their websites to be properly secured against hackers.

Users mean very well and want to help others, but this has created WordPress myths surrounding security.

These are the 7 WordPress myths that don't make your website any better secure at all.

1. Moving or hiding WP Admin will stop brute force attacks

Force attacks occur as malicious bots repeatedly try to guess your username and password to gain access to your website's backend. From there, they can lock you down, compromise your data and take down the website. They often try usernames like admin with thousands of passwords in the hope that something will work.

Because the bots attack the login page, a logical step for many users is to hide their wp-admin folder or at least move their login page. There are many plugins that make this possible. Still, this is not the solution for several reasons:

1. Many plugins and features depend on the wp-admin folder where it resides. If anything about that folder changes, a plugin or feature may break. Therefore, we recommend changing a the wp-login.php page or using password protection only if it is really necessary.

(2) "Security through obscurity." With this approach, you increase the security of your data by hiding an access point. Depending on a hidden page on your site is generally not the best approach to online security. Any hacker with the right tools can break into your website and still very easily find where your login page is hidden. It doesn't matter where you've hidden it. It's not really an effective way and can cause more problems than it ultimately solves.

3. The majority of attacks are not on the login page. They often try to log in via XMLRPC, which is how other applications log in to communicate with your Web site.

2. Changing the WordPress Table Prefix will improve security

A few years ago, this idea suddenly became very popular. This would prevent SQL-injection attacks on your website, where the attacker uses a security hole in your WordPress plugins or themes to gain access to your database. By changing your predictable database table prefix and "wp_" to something else, you could somehow prevent these attacks.

However, there is no reason to believe that this is true. In fact, it can put your Web site at risk. The best protection against SQL injection attacks, is a three-part approach with a powerful Web Application Firewall. This firewall continuously monitors your website against malware and keeps your plugins, themes and core files up-to-date.

3. All you need to lock your website is a secure username and password

Of course, a strong password and unique username is an important part of securing your website. After all, one of the basic techniques of hacker bots is to try thousands of passwords using the default WordPress username "admin." By changing your admin username, you are already one step ahead. Especially when combined with a password that consists of uppercase, lowercase, numbers and special characters.

But even if you have this, hackers will still find other ways to hack your website. For example, through security holes in outdated plugins, data breaches or phishing. Secure usernames and passwords cannot be your only strategy to protect your website. Additional authentication, such as via your phone, is a crucial layer of security to secure your login data. This makes it more difficult for hackers to break in.

4. My website is not interesting enough for hackers

Many Web site owners believe that their Web sites are not interesting enough for hackers. They believe that hackers only target certain companies rather than small or unimportant ones.

Unfortunately, this is not true. According to a 2014 study, 60% of all website attacks were on small to medium-sized businesses. Precisely because smaller businesses simply do not have the supplies and security to prevent these attacks. This makes smaller businesses easier and more interesting to hack than larger, robust websites. Another study shows that 60% of these small businesses had to close their doors within a year due to the cyberattack.

Your website does not have to have a high profile or millions of visitors at all to be of interest to a hacker. Once they have access to the website's administrator functions and back-end, they can damage everything, send spam to people or completely destroy your website.

No website is too small to be hacked. As a website owner, you should always take every precaution to protect your data from hackers and cyber attacks.

5. My website is secure because it has an SSL certificate

An SSL (Secure Socket Layer) certificate does indeed add an extra layer of security to the communication between your Web site and visitors. This is especially important when visitors share personal information, such as a credit card number. An SSL certificate ensures that this data is encrypted and cannot be viewed in plain text if a data breach occurs.

Want to read more about an SSL certificate? Read our previous blog >>

So it protects the information of your visitors, but certainly not the data of the website itself. Without a web application firewall, up-to-date plugins, software and other security measures, your website remains accessible to hackers and customer data is also at risk. 

6. My website uses a CDN or Cloud-based Firewall, which is the same as a Wordfence Firewall

Content delivery networks (CDNs) and cloud firewall providers provide security for your Web site by routing and filtering traffic through their server based on firewall rules. They then forward only traffic that meets these rules to your Web site. The expectation is that this route hides your actual website login, because every visitor is automatically redirected to the cloud firewall provider's server instead of yours.

In reality, it is virtually super easy for anyone to bypass the cloud firewall and get behind your website's original IP address and attack the website directly. Keeping your original IP address secret is very difficult, and virtually impossible. Therefore, this is a well-known problem with cloud firewall solutions. Wordfence best supports the protection of your data against possible attacks on the original site.

7. WordPress itself is an insecure platform

WordPress is currently the most popular content management software. Therefore, WordPress has undergone a number of security makeovers in recent years. But a weakness in WordPress would put a very large number of websites at risk. This is why some people condemn WordPress as an insecure platform. But this is anything but true.

Of course, WordPress is more prone to attacks than less popular content management systems (because it is more widely used), but that does not make WordPress any less secure. Precisely because WordPress has millions of websites, it has an active team of developers working together 24/7/365 to find and prevent any security threats. There is no CMS that once a threat is identified has an immediate fix.

80% of hacking incidents occur because of outdated software and/or a weak username and password combination or a security flaw that was not fixed in time, but not a flaw in the software itself.

Conclusion

Maintaining and optimizing the security of your Web site may seem like a complicated task. As a website owner, you may struggle to follow all the information and advice. But with a good firewall, a secure username and password with 2-factor authentication and the most up-to-date software, you can make it as difficult as possible for hackers!

Want to know more about securing your WordPress website?

Get in touch with our web team!

Contact button SearchUser

Share this article via
Patrick Schokker
Patrick Schokker

About this schurq

General Manager

Also read
|
Shannah de Ruijter
|
2 minutes

Short videos

|
Lysanne Paulus
|
2 minutes

Google Consent Mode V2

|
Guido Sombroek
|
4 minutes

Server Side Tagging explained simply