How to Harden WordPress Without a Plugin

Hardening WordPress without a security plugin means reducing avoidable risk through WordPress configuration, server controls, access policies, deployment practices, backups, and monitoring. It does not mean that plugins are always bad. It means the foundation should remain secure even when no all-in-one security plugin is active.

Short answer: Start with updates, least-privilege access, multifactor authentication, secure hosting, tested backups, restricted file writes, protected secrets, logging, and a recovery plan. Apply every change in staging first because server rules can break logins, APIs, cron jobs, and publishing workflows.

What WordPress hardening can and cannot do

Security is risk reduction, not a promise that a site can never be compromised. The official WordPress hardening guidance separates responsibilities across the device, network, server, database, application, and people using the site. That layered view is more useful than copying a list of snippets.

A plugin-free baseline can reduce attack paths and limit damage. It cannot replace vulnerability monitoring, incident response, a web application firewall when the risk justifies one, or expert review for regulated and business-critical platforms.

Prioritize controls by risk

• Critical: patch supported WordPress core, plugins, themes, PHP, database, and server software.
• Critical: require unique accounts, strong passwords, multifactor authentication, and prompt access removal.
• High: protect backups, credentials, deployment keys, and production configuration outside the public web root.
• High: limit write access and prevent production code edits through wp-admin.
• High: collect logs, alert on meaningful changes, and rehearse restoration.
• Context dependent: block XML-RPC, add HTTP authentication, or make code read-only only after checking integrations.

1. Keep every supported component patched

Most WordPress incidents begin with an exposed credential, an outdated extension, or unsafe custom code. Maintain an inventory of core, themes, plugins, PHP, database, web server, CDN, and external services. Remove inactive extensions instead of leaving them installed. Test updates in staging, take a recoverable backup, deploy through a controlled process, and verify the site afterward.

For a practical policy, see the WordPress automatic updates guide. Enterprise teams should define who reviews security notices, how quickly each severity is patched, and who can approve an exception.

2. Strengthen identity and access

Give every person a named account and only the capabilities required for their work. Avoid shared administrator accounts. Require multifactor authentication at the identity provider or hosting layer, and protect the email accounts used for password resets. Review administrator, editor, API, SFTP, SSH, database, CDN, DNS, and hosting access on a schedule.

For agencies and larger teams, use single sign-on where suitable, retain an audited emergency account, and remove access as part of offboarding. A secure WordPress login is not enough if a former supplier still controls DNS or a deployment key.

3. Disable dashboard file editing

If an administrator account is compromised, the built-in theme and plugin editors can provide a direct route to changing executable code. Add this constant to wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

This removes the dashboard editors. It does not stop an attacker who already has another method of writing files. For controlled deployments, consider DISALLOW_FILE_MODS only when updates and installations are handled through CI/CD. Test carefully because it also disables dashboard updates.

4. Protect wp-config.php and secrets

Keep database credentials, salts, API keys, and environment-specific secrets out of version control. Limit filesystem access to the operating-system user that needs it. WordPress can read wp-config.php from one directory above the installation, but moving it is not a substitute for correct permissions and server configuration.

On Apache 2.4, a defense-in-depth rule can deny web access to the file:

<Files "wp-config.php">
    Require all denied
</Files>

NGINX and managed platforms use different configuration. Ask the host for the supported rule instead of pasting Apache directives into an unrelated stack.

5. Apply least-privilege file ownership

The official guidance uses 755 as a common directory baseline and 644 for files, while noting that ownership and hosting setup matter. Do not solve permission errors with 777. WordPress core, themes, and plugins should not be broadly writable. The uploads directory needs controlled writes, but it should not execute PHP.

find /path/to/wordpress -type d -exec chmod 755 {} +
find /path/to/wordpress -type f -exec chmod 644 {} +

Run recursive permission commands only when you understand the owner and group model. A wrong command can expose secrets or make the site unavailable.

6. Block PHP execution in uploads

Uploads normally contain media, not application code. At the web-server or container layer, deny PHP execution inside wp-content/uploads. The exact rule depends on Apache, NGINX, PHP-FPM, or the hosting platform. Verify image processing, protected downloads, and any plugin that legitimately writes generated files.

7. Reduce exposed interfaces

Disable an interface only when it is not required. XML-RPC may support remote publishing, mobile apps, Jetpack, and integrations. If it is unused, block xmlrpc.php at the edge or server and test the result. Read the dedicated guide to disabling XML-RPC before changing production.

Disable directory indexes, enforce HTTPS, redirect HTTP safely, and use secure cookies. Rate-limit abusive login traffic at the CDN, load balancer, or web server. IP allowlists can suit tightly controlled administrative workflows, but they are inconvenient for distributed teams and should have an emergency procedure.

8. Secure the database and separate environments

Use a dedicated database and database user for each important site or environment. Do not share production credentials with development. Restrict network access to the application hosts that need it and encrypt connections when traffic crosses an untrusted network.

Changing the default table prefix may stop simplistic automated probes, but it is not a meaningful defense against a vulnerable query. Prioritize patched code, parameterized database access, limited credentials, network controls, and reliable backups.

9. Make backups recoverable

A backup is valuable only if it can be restored. Keep database, uploads, code references, and environment configuration on a schedule that matches the business recovery point. Store copies outside the production account, restrict deletion, encrypt sensitive data, and test restoration.

Define both the recovery point objective, which is how much data the business can lose, and the recovery time objective, which is how long recovery may take. Record the restore steps and assign an owner.

10. Monitor changes and prepare for incidents

Collect web server, PHP, authentication, deployment, CDN, and WordPress activity logs in a place an attacker cannot easily erase. Alert on new administrators, unexpected code changes, repeated authentication failures, disabled security controls, and unusual outbound traffic. Keep logs only as long as justified and protect personal data.

For business-critical platforms, turn these practices into policy through enterprise WordPress security governance. Your response plan should cover containment, evidence preservation, credential rotation, clean restoration, communication, and a post-incident review.

A safe implementation sequence

• Inventory the platform, integrations, owners, data, and business impact.
• Fix unsupported software and exposed privileged accounts first.
• Create and test a restorable off-site backup.
• Apply one control in staging and document the expected result.
• Test login, publishing, media, forms, cron, APIs, cache, deployment, and rollback.
• Deploy during an approved window and watch logs and business journeys.
• Record exceptions, owners, review dates, and recovery instructions.

Common hardening mistakes

• Treating a renamed login URL or database prefix as the main defense.
• Blocking XML-RPC without checking mobile, Jetpack, or publishing integrations.
• Using 777 permissions to solve deployment problems.
• Putting secrets in Git, build logs, tickets, or shared chat.
• Making production read-only without a tested update and rollback path.
• Assuming the host protects vulnerable application code.
• Keeping backups in the same account with the same credentials as production.

When a security plugin or managed service is still useful

A focused tool may be appropriate for multifactor authentication, audit logging, malware detection, or integration with a security operations platform. A network WAF can filter traffic before WordPress runs. Choose controls from the threat model, not from the number of features in a dashboard.

If the site is revenue-critical, regulated, frequently targeted, or managed by several teams, an independent WordPress security hardening assessment can identify gaps across code, hosting, identity, operations, and recovery.

Sources and further reading

• WordPress Developer Resources: Hardening WordPress
• WordPress roles and capabilities
• WordPress backups

Frequently asked questions