## Securing a WordPress site URL: https://hub.jkdevstudio.com/knowledge-base/best-practices/securing-a-wordpress-site Updated: 2026-09-15 Summary: How WordPress sites really get hacked, the basics that stop most attacks, how to check a plugin for known vulnerabilities, and what to do after a compromise. Most WordPress sites are broken into through an outdated plugin, a weak password or a pirated download, not through anything sophisticated. This page explains how attacks happen and the basics that stop most of them. It applies to any WordPress site, and the last sections explain how our themes and plugins fit in. ## What website security means A site is secure when nobody but you can control it, read data they should not, or use your server for their own purposes. When that fails, the attacker usually does not deface the homepage. They add spam pages, redirect visitors to scams, steal customer data, or use the server to send spam, and the site owner finds out from a browser warning or an email from the host. A few words that come up whenever security is discussed: :::deflist Vulnerability : A mistake in code that lets somebody do what they should not be able to. Most WordPress vulnerabilities are in plugins. Exploit : A working method of using a vulnerability. Once a vulnerability is published, automated tools try it on millions of sites within days. Backdoor : Hidden code that gives an attacker a way back in, even after passwords change. Malware : Any malicious code planted on the site: backdoors, spam injectors, redirects, card skimmers. SSL certificate and HTTPS : The certificate lets the browser talk to your site over HTTPS, an encrypted connection. Without it, passwords and form data travel in readable form. ::: ## How WordPress sites actually get hacked :::deflist Outdated and abandoned plugins : By far the most common way in. A plugin with a published vulnerability that nobody updated, or a plugin its author stopped maintaining years ago. Weak or reused passwords : Bots try common passwords on `wp-login.php` all day long (brute force), or try passwords leaked from other sites (credential stuffing). An old account named `admin` with a simple password is the classic target. Too many users with too much access : Former contractors, test accounts and authors who were given administrator rights "for a moment". Every account that can install plugins is a way in. Nulled themes and plugins : Paid products redistributed for free on mirror sites, very often with a backdoor added. The download itself is the attack. The hosting account : A leaked FTP or control panel password, or on cheap shared hosting, another infected site on the same account. Outdated PHP and WordPress : Old versions stop receiving security fixes. A PHP version past its end of life is not patched at all. ::: Behind these sit a handful of classic attack types you will see named in security reports: SQL injection (tricking the site into running database commands), cross-site scripting or XSS (injecting scripts into pages other people view), CSRF (tricking a logged in admin into performing an action) and arbitrary file upload. The [OWASP Top Ten](https://owasp.org/www-project-top-ten/) is the standard reference if you want to go deeper. ## HTTPS is not optional Every site needs a valid SSL certificate and every page served over HTTPS. Without it, anyone on the same network can read the admin password as you log in, browsers mark the site "Not secure", and search engines rank it lower. Most hosts issue a free certificate from Let's Encrypt in a click. The WordPress Address and the Site Address in [[Settings > General]] must both use HTTPS. How to set it up before installing a theme is covered here: Setting up your domain and HTTPS before installing ## The basics, in the order that matters :::steps ### Keep everything updated WordPress, PHP, the theme, the Pro plugin and every third party plugin. Most published vulnerabilities are already fixed in a newer version by the time attackers use them. ### Delete what you do not use A deactivated plugin is still code on your server, and its files can still be reachable. Delete it instead of deactivating it. The same goes for old themes you do not use, except one default WordPress theme kept as a fallback. ### Use strong, unique passwords and two-factor authentication A password manager, a unique password per account, and two-factor authentication on every account that can install code. The [Two Factor](https://wordpress.org/plugins/two-factor/) plugin maintained by WordPress contributors is enough for most sites. ### Review who has access Open [[Users]] and remove accounts nobody uses. Give people the lowest role that does the job: an author does not need to be an administrator. Most sites need exactly one administrator. ### Turn off the built-in file editor The admin can edit theme and plugin files directly, which also means anyone who steals an admin password can. Add this line to `wp-config.php` to remove the editor: ```php title="wp-config.php" define( 'DISALLOW_FILE_EDIT', true ); ``` ### Set up automatic backups stored somewhere else Daily, kept off the server, and tested by actually restoring one now and then. A backup on the same server disappears with the server. ::: WordPress keeps a longer checklist in its [hardening guide](https://developer.wordpress.org/advanced-administration/security/hardening/). ## How to check whether a plugin is safe Before installing a plugin, and every few months for the ones you already have: - [ ] **Last updated.** On the plugin's wordpress.org page, a plugin not updated in over a year is a risk, and a notice that the plugin "has been closed" means stop using it. - [ ] **Changelog.** Look for entries such as "security fix" and check you are on that version or newer. - [ ] **Known vulnerabilities.** Search the plugin's name in a public database: [Wordfence Intelligence](https://www.wordfence.com/threat-intel/vulnerabilities/), [WPScan](https://wpscan.com/) or [Patchstack](https://patchstack.com/database/). Each entry shows which versions are affected and which version fixed it. - [ ] **Where it came from.** wordpress.org or the developer's own site. Never a "free download" of a paid plugin. ## Do you need a security plugin? One can help: it adds a firewall, blocks repeated login attempts, scans files for known malware and warns you about vulnerable plugins. Well known options are [Wordfence Security](https://wordpress.org/plugins/wordfence/), [Solid Security](https://wordpress.org/plugins/better-wp-security/) and [Sucuri Security](https://wordpress.org/plugins/sucuri-scanner/).
**Install one security plugin, not three.** Several at once conflict with each other, slow the site down and send so many notifications that you stop reading them. None of them replaces updates, passwords and backups.
A good host matters as much as any plugin: one that patches its servers, isolates accounts from each other, keeps backups and gives you access logs. ## Where our responsibility starts and ends We are responsible for the security of the code we write: our themes, the Pro plugins, and our integrations. We are not responsible for the security of your site as a whole, which depends on your hosting, your passwords, your users and every other plugin you install. The [Terms & Conditions](https://jkdevstudio.com/terms-conditions/) provide the products as they are and ask you to keep backups, and support does not cover [third party plugins](/knowledge-base/best-practices/third-party-plugins). What we do on our side: :::deflist Nonces and capability checks : Every admin action checks that the request comes from a logged in user with the right permission, and carries a WordPress nonce, a one-time token that stops CSRF. Sanitizing input and escaping output : Everything that comes in is cleaned before it is stored, and everything printed on a page is escaped, which is what prevents injection and XSS. Server-side processing : Decisions that matter, such as license activation and verification, are made on the server. The license response is cryptographically signed, so it cannot be faked in the browser or the database. No sensitive data on the front end : Your purchase code is not printed into pages, and API keys saved in the theme settings are stored encrypted in the database. ::: If you believe you have found a vulnerability in our code, report it privately through a support request with the **Security** category, not in a public comment or review. ## Nulled and unofficial copies
**A theme or plugin from a mirror or "free download" site is the most reliable way to get a backdoor installed.** Adding malicious code is how those files pay for being free. If a site running a nulled copy of our theme or Pro plugin is compromised, we carry no responsibility for it whatsoever and support will not look at it, as the [Terms & Conditions](https://jkdevstudio.com/terms-conditions/) state.
Why nulled copies do not work ## If you think the site is compromised Signs to take seriously: administrator accounts you did not create, pages or links you did not write, visitors redirected to another site, a warning from your host, Google or the browser, and files with recent change dates you cannot explain. The first safe steps: - [ ] Take a full backup as it is now, even though it is infected, so the attack can be investigated later - [ ] Change every administrator password, and your hosting, FTP and database passwords - [ ] Remove accounts you do not recognize - [ ] Update everything - [ ] Restore from a clean backup made before the problem started, if you have one Cleaning a compromised site properly is specialist work. Restoring a clean backup and then closing the way in is faster and more reliable than hunting for injected code by hand. Our [Support Policy](https://jkdevstudio.com/support-policy/) does not include diagnosing or cleaning hacked sites. Once the site is clean, anything still wrong in our product is a normal support request. ## Common questions
Is WordPress itself insecure? No. WordPress core is maintained by a large security team and patched quickly. The risk lives in what people add to it and in how long they leave it unpatched.
A security scanner flagged a file in your theme First compare the file with a fresh download of the same version from your Hub account. If they differ, something changed the file on your server, and that is the real finding. If they match and the scanner still flags it, send a support request with the **Security** category, the file path and the scanner's report.
Should I hide the WordPress version or the login page address? It reduces noise from bots a little and stops nobody who is actually targeting you. The same half hour spent on updates and two-factor authentication does far more.
My host says the site is clean, and it still redirects Check for injected code in the database as well as in the files. Then clear every cache, because a cached copy of an infected page outlives the infection that produced it.
I cannot get back into the admin at all Contact your host. They can reset access at the database level faster than anything you can do from outside, and without destroying the traces of how the attacker got in.
Does a security plugin slow the site down? Some features do, especially frequent full file scans on cheap hosting. Schedule scans for quiet hours and turn off features your host already provides, such as a firewall at the server level.