WordPress security: layer-by-layer precautions to protect your website from hacking

WordPress security is achieved through layers consisting of up-to-date software, strong login protection, limited permissions, hardened server settings, and regular backups, rather than through a single plugin. WordPress’s official hardening documentation defines security as reducing risk rather than eliminating it: the aim is to make the attacker’s job harder and limit the damage even if an attack succeeds.

This guide focuses on precautions to take before a website is hacked, and bases every step on official WordPress.org documentation. If an attack has already occurred, the procedure is different; cleanup, removing Google warnings, and renewing access credentials are addressed in the process of recovering a hacked WordPress website following an attack.

Is WordPress secure, and where does the risk come from?

WordPress core is software continuously monitored by its own security team, with patch releases published when vulnerabilities are found; most risks arise from how the website is managed rather than from the core. According to the WordPress security page , only the latest version is officially supported; the team also backports critical fixes to older versions as a courtesy, but this is not a commitment.

The hardening documentation emphasizes that websites are rarely compromised because of infrastructure and are usually compromised through the application layer for which the website owner is responsible. The hosting company protects the server; installed themes, plugins, user accounts, and passwords are the website owner’s responsibility. Most attacks are carried out by automated bots targeting known vulnerabilities in outdated components or predictable passwords.

The official documentation also reminds readers that the chain begins with the website administrator’s own computer. On a computer infected with malware that steals keystrokes, none of the server’s precautions can protect the password. Keeping the operating system and browser updated and avoiding administration panel logins over open, unencrypted wireless networks are therefore the first link in WordPress security.

Updates: the most basic WordPress security precaution

Outdated core software, themes, and plugins are the most common entry points, because once a vulnerability is fixed, the information needed to exploit it also becomes public. WordPress’s hardening documentationstates that keeping old versions updated is therefore the most basic precaution. Automatic background updates have existed in the core since WordPress 3.7; WordPress 5.5 made it possible to enable automatic updates separately for each plugin.

Automatic updating is fast from a security perspective, but during major version upgrades, a plugin may break the website. For this reason, a controlled sequence is followed, especially on ecommerce websites or sites that rely heavily on forms:

  1. Back up the files and database immediately before updating.
  2. If possible, test the update on a test copy of the website first.
  3. Apply the update on the live website; do not delay minor releases containing security fixes.
  4. Manually check critical functions such as the homepage, forms, cart, and member login.
  5. Note components that have not been updated for a long time or have been removed from the directory, and look for alternatives.

The PHP version on the server is also part of this chain. A PHP version whose support period has ended no longer receives security fixes and may cause incompatibilities with current plugins.

Strong passwords, two-step authentication, and passkeys

Login security relies on unique, long passwords and two-step authentication enabled on all administrator accounts. WordPress’s brute-force attacks documentationrecommends using a password manager and enabling two-step authentication on all privileged accounts; according to the documentation, this feature is not included in the core and is added through a plugin or enterprise identity provider.

The same documentation mentions passkeys (WebAuthn), which allow login through a fingerprint, facial recognition, or a security key on the device instead of a password, as a phishing-resistant option and recommends registering at least two authenticators for each administrator. This prevents someone who loses their phone from being locked out of their account.

The hardening documentation also lists what to avoid when choosing a password: passwords derived from the person’s, company’s, or website’s name; dictionary words in any language; short passwords; and strings consisting only of numbers or only of letters. WordPress also provides a strength indicator on the password change screen; a password marked as weak should not be accepted.

There is also a separate rule for external applications connecting to the website: these services should not receive the administrator password. Application passwords, introduced with WordPress 5.6, allow a separate key to be created for each integration and revoked when necessary without changing the main password.

Page contents

Trustworthy web agency: handshaking client and team, trust shield illustration

Limiting attacks against the login page

Login attempts should, if possible, be limited at the server or firewall level before the attack reaches WordPress. The brute-force documentation reminds readers that application-level login-limiting plugins still run through PHP during an intensive attack and consume server resources. Rate limiting at the edge network or server is more efficient. Human verification added to the login form slows bots down; setting up alerts for unusual login activity and temporarily blocking attacking IP addresses are also among the steps listed in the documentation.

The XML-RPC interface (xmlrpc.php) is frequently targeted because it can allow numerous password attempts in a single request; disabling it if unused and restricting it if used are recommended. Changing the login page address may reduce noise from automated scanning, but according to the official documentation, it should not be considered the only defense. For the same reason, easily guessed usernames such as “admin” or “webmaster” are also avoided.

User roles and the principle of least privilege

Each user should receive the lowest role sufficient to perform their work; if an account is compromised, the damage is limited to that account’s permissions. WordPress’s default roles and capabilities are as follows:

RoleWhat they can doWho receives it?
AdministratorAll settings, users, theme and plugin managementOne or two people technically responsible for the website
EditorPublishing and editing all content, including other people’s posts; adding unfiltered HTML on single-site installationsA trusted team member responsible for content
AuthorPublishing and managing their own postsAn employee who regularly produces content
ContributorPreparing posts without being able to publish themPeople submitting posts from outside the organization
SubscriberManaging only their own profileRegistered visitors

The Editor role’s ability to add unfiltered HTML on single-site installations shows that this role should not be considered harmless either. Agency and freelancer accounts should be closed when their projects end, and everyone should use an account created in their own name. The “new user default role” on the Settings page should remain Subscriber; if membership is unnecessary, registration for everyone should remain disabled.

Let’s review your website’s security layers together

Update status, administrator accounts, login protection, and the backup setup are checked individually in a free preliminary assessment. Missing precautions and which one to start with are explained clearly; no promise of absolute protection is made, and the areas where risk is concentrated are shown.

Disabling theme and plugin editing in the dashboard

By default, WordPress allows administrators to edit theme and plugin files through the dashboard; this feature should be disabled. The hardening documentation states that this editor is the first tool an attacker uses upon entering the dashboard because it allows code execution. The line define( 'DISALLOW_FILE_EDIT', true ); added to wp-config.php removes theme, plugin, and file-editing capabilities from all users.

The documentation also explicitly states that this setting does not prevent malicious file uploads but may stop some attacks. Options for unfiltered file uploads, such as SVG or JSON, in page builder settings should also be enabled only when truly necessary; these files can carry malicious code. Plugins that allow execution of code written into the database are avoided where possible because they increase the damage after an attack.

File permissions, wp-config.php, and the database

File permissions should be kept as restrictive as possible, and write permission should be given only to folders that require it. In the example arrangement in the official documentation, folders have permission 755 and files have permission 644, with write access distributed by folder as follows:

  • Root directory, wp-admin, and wp-includes: only the website owner’s user account can write
  • wp-content: both the user account and web server can write, because uploads go here
  • wp-content/plugins: only the user account can write
  • wp-content/themes: only the user account can write if dashboard theme editing is disabled

For wp-config.php, which contains database connection details and security keys, the documentation recommends permission 400 or 440 and blocking direct access through server configuration.

SFTP is used instead of unencrypted FTP for transferring files to the server, so the password does not travel over the network in plain text. If there are multiple WordPress websites on the same server, running each with a separate database and database user makes it harder for a compromise of one website to spread to the others. According to the documentation, using a table prefix other than the default “wp_” can also thwart some automated SQL injection attacks.

Transparent pricing: calculator and budget planning illustration

Theme and plugin sources: the trusted-source rule

Themes and plugins should be obtained only from the WordPress.org directory or the websites of known developers. The hardening documentation explicitly warns that components downloaded from untrusted sources can cause problems; cracked copies of paid plugins distributed “free” often contain backdoors.

Unused components should be deleted rather than merely deactivated. WordPress’s Site Health screen also states that inactive plugins are attractive targets for attackers and recommends removing plugins that will not be used. As their number decreases, the number of updates and potential vulnerabilities that need monitoring also decreases.

If a plugin requests write access to files during installation, the official documentation recommends reviewing its code or consulting someone trusted. Before adding a new plugin, also read the maintenance information in the directory: when the plugin was last updated, which WordPress version it has been tested up to, and the issues left unanswered in its support forum.

Hosting, servers, and firewalls

The server hosting the website is an invisible but decisive layer of WordPress security. The official documentation states that when another website on a shared server is compromised, other websites may also be affected, and expects a reliable hosting company to answer security questions clearly, keep server software updated, and provide reliable backup and restoration capabilities. These criteria should be discussed during hosting selection for the website.

A web application firewall (WAF) can operate at three levels: as a plugin running within WordPress, as a module installed on the server, or as a reverse proxy and content delivery network filtering traffic before it reaches the website. Layers that stop traffic before it reaches the origin also avoid burdening the server. Placing a second password on the wp-admin folder at server level is another method mentioned in the official documentation; however, it is applied carefully because incorrect configuration can break features operating through admin-ajax.php. The choice depends on the website’s traffic, hosting type, and management capacity.

If precautions are not enough: backups, logs, and change monitoring

Because no precaution eliminates risk completely, preparation that enables early detection of an attack and rapid recovery is also part of security. The hardening documentation explains the importance of full website copies taken at regular intervals with an example: if a website compromised on May 1 is discovered on May 12 and weekly copies exist, a clean backup from before the attack is available, and subsequent copies help reveal how the attack happened.

The backup itself must also be protected. The documentation lists encrypting backups, keeping an independent hash record for each backup file, or storing them on read-only media as ways to ensure the data has not been modified afterward.

Server access logs show brute-force attempts and suspicious requests. A system monitoring file changes catches unexpected additions, particularly to PHP files, early. This monitoring is among the regular tasks in WordPress maintenance and updates work.

WordPress security checklist

The following list can be used to review a website’s basic security status quickly. Each item is explained in the sections above:

  • Core software, themes, plugins, and PHP version are up to date
  • Unused themes and plugins have been deleted
  • Two-step authentication is enabled on all administrator accounts, and passwords are unique
  • There is no “admin” username, and former staff and agency accounts have been closed
  • Each user has the lowest role sufficient for their work
  • File editing through the dashboard is disabled
  • XML-RPC is disabled if unused, and login attempts are limited
  • File transfers use SFTP, and access to wp-config.php is blocked
  • Backups are regular, stored separately from the website, and restoration has been tested
  • The website opens over HTTPS, and administration panel logins use an encrypted connection

Most items on the list are performed once and remain in place; updates, account cleanup, and backup checks require ongoing monitoring. If the website starts displaying errors after an update, the source of the problem is identified through WordPress troubleshooting steps; a temporary fix is not sought by relaxing security precautions.

Let’s plan security precautions according to your website

Every website has different risks: a promotional website, membership system, and ecommerce store do not have the same priorities. A short review is sufficient to see which layer is missing from your WordPress security. Sending a WhatsApp message or calling is enough to start a free preliminary assessment.

Related guides

Frequently asked questions

WordPress core is software monitored by a security team, with patch releases published for vulnerabilities. Most risks arise from management mistakes such as outdated plugins, weak passwords, and accounts with excessive permissions.

It is not essential; a plugin alone does not provide security, but is a layer alongside updates, permission management, and backups. Protections such as login limiting and firewalls are implemented at server or edge-network level where possible.

According to the official documentation, two-step authentication is not included in the core; it is added through a reliable plugin or enterprise identity provider. Enabling it on all administrator accounts and registering multiple authenticators for each account are recommended.

It may reduce noise from automated bots, but according to WordPress’s official documentation, it should not be used as the only defense. Strong passwords, two-step authentication, and server-level login limiting provide the main protection.

This setting, added to wp-config.php, disables editing of theme and plugin files through the dashboard for all users. It makes it harder for an attacker who enters the dashboard to add code directly, but does not prevent malicious file uploads on its own.

It can; as long as its files remain on the server, vulnerabilities within it can be exploited. WordPress’s Site Health screen also recommends deleting plugins that will not be used.

Releases containing security fixes should be applied without delay after publication. Major version updates are performed after taking a backup first and, where possible, testing on a test copy.

Onur Ertem - Onur Freelance Corporate Web Design

Onur Ertem

Strengthen your business online! 🚀 Are you ready to grow your brand with corporate web design and digital marketing solutions? Contact us now and stand out in the digital world with our professional support!

Phone-alt Whatsapp

Call us

Call us for detailed information.

Let us call you!

Share your number and let us call you!

Our other services

Service areas

Contact information