Although the web is full of different engines and methods for building websites from scratch, quite often we see that clients expect layouts, themes, templates, plugins, or complete projects specifically for WordPress from web designers or front-end developers. Sometimes it's about configuring an existing, already launched site, resolving issues with security, code quality, plugin performance, and more. One way or another, even if WordPress seems simple, user-friendly, lightweight, and straightforward—building a truly high-quality website on it still takes effort.

But what sets this CMS apart from many others is security. And WordPress doesn’t have the best reputation in this regard. Yes, it’s improving year by year, but still, over 50,000–70,000 sites get hacked annually. Automatically, at scale. And it’s not just the CMS creators’ fault for leaving vulnerabilities (and later issuing patches ), but also the users, developers, and administrators themselves.

No, they’re not clueless about security — they do take some steps — but often it’s just not enough. We’ll explore areas that take more effort than simply installing a security plugin or changing a few settings. However, you’ll need to work with WordPress code directly.

Hacking Patterns

If we analyze the main reasons WordPress gets hacked, it’s usually due to outdated versions. Most often, five versions or more behind the latest — sometimes even just one version behind if a critical patch was released. While modern versions of WP are also targeted, it’s less common. Aside from the core, hacks often come through plugins, themes, configurations, or even through the server — which falls on the admin.

It doesn't matter what kind of site you're building — a café, a portfolio, a company site, a small e-commerce store — it will likely be targeted eventually. Bots don’t care what the site is; they look for opportunities to send spam, attack other servers (using your traffic as a redirect channel to overload a target server), mine cryptocurrency (dedicated servers are expensive), steal user data, conduct "shadow" SEO, and more.

So, it's easy to imagine the consequences for admins, users, owners, and clients: reputational damage, financial loss, and a lot of stress.

The Holy Trinity of Protection

The three key principles of information security were defined in 1975 and are still used today. They've evolved but the core concepts remain. Let’s look at how each of them can apply to WordPress security.

Integrity

Don’t blindly trust everything. Always verify the intent of user actions and the integrity of processed data. Nothing online is inherently trustworthy — double-check everything to prevent malicious behavior. WordPress handles core data validation quite well. But this only applies to the CMS core. If you’re developing a custom plugin, theme, or even integrating third-party code, you’ll need to handle validation yourself.

In the example below, we’re updating post meta with two types of data. The first is a string, cleaned using the sanitize_text_field sanitization function ( read more). The second part checks that a number is positive using absint.

This approach is preferable to database-level analysis. Here, all data written to the database gets checked, helping prevent SQL injections. An SQL Injection attack runs malicious SQL via an ordinary form, letting attackers manipulate the database to erase data, steal credentials, or create fake admin accounts.

To protect against SQL injection, use prepare and the wpdb class. The example below uses $wpdb->prepare to validate variables before executing a query on my_table.

For XSS (Cross-Site Scripting) attacks, escaping data is critical. These attacks inject malicious scripts into your frontend. Escaping ensures your markup remains valid. WordPress offers many escaping functions and usage rules.

Admin-level requests are only safe when SSL is in place. Always verify the user making the request. WordPress uses nonces (number used once). These work like CSRF tokens and help prevent repeated or spoofed requests. WordPress supports them for compatibility, even though they’re not true cryptographic nonces.

Nonces are sent with every vulnerable user request — added to URLs and forms — and must be verified before executing actions. You can use nonce in form code or URLs. Here's an example with a form:

We use the wp_nonce_field() function, which generates two hidden fields. One verifies the action 'post_custom_form', the other uses a referrer check to confirm the request came from within WordPress.

Before processing the form, the nonce must be validated using wp_verify_nonce. If it fails, processing should stop.

One of the most common but overlooked risks are plugins and themes — even those from official sources. They may work fine for a while, but eventually vulnerabilities emerge. No software is 100% secure. Many plugins aren’t updated, or were unsafe to begin with.

Less code means fewer attack surfaces. Before installing another plugin, ask yourself: “Do I really need this? Is there another way to solve this?” If you do install one, research it. Check reviews, last update date, and PHP version compatibility. Look it up on security blogs like Sucuri or WordFence.

Another step is scanning plugin code to ensure it uses nonces, escaping, and sanitization. These are signs of secure coding. You don’t need full PHP expertise — a quick way is to search plugin files for: $wpdb->prepare; wp_nonce_url; esc_html; sanitize_text_field; wp_nonce_field; esc_attr.

Also be cautious of community-developed plugins. Tools like Composer and NPM use shared libraries — many attacks come from them.

Availability

This principle means your site should always be online. If something breaks — you need a backup. Don’t skip backups. Also, many issues are fixed by disabling plugins and updating WordPress core, then gradually restoring or removing plugins. There are tools for bulk updates by WP core developer Mark Jaquith — but you lose visibility into what’s breaking.

Services like Sucuri can detect malicious code and core file damage. They won’t fix it (unless paid), but they’ll tell you what to look for — even in free mode.

Confidentiality

Even if your site’s code is secure, the internet is not. Confidentiality means educating yourself, your client, and users. For instance, if you have WP_DEBUG set to true, any hacker will see your directory path. Never use debug mode on live sites.

Another vulnerability is user comments and author pages — they often contain usernames and email addresses. Hackers can use them with common passwords to access your site.

And yes — passwords, salts, keys — make them complex and unique.

Conclusion

Yes, WordPress is constantly updated and becoming more secure. But the environment around it remains risky. So users and admins must either deal with infections or proactively defend against them. Whether you write templates, plugins, or just use ready-made themes — security is your responsibility. Even if it feels overwhelming.

Remember the key lines of code, test and verify all plugins and themes, enforce strong authentication — and you can handle even large-scale threats. We didn’t cover server config files here — the goal was to highlight rarely discussed but important aspects of WordPress security.