WordPress Security, Backups and Recovery: Build a Site That Can Survive Failure

SECURITY IS RISK MANAGEMENT

Protect the things that matter, reduce likely attack paths, contain damage and preserve recovery options.

No public website can be made absolutely secure. Professional security therefore works in layers: prevent common attacks, detect abnormal behavior, contain the blast radius, recover from a known-good state and improve after the incident. WordPress itself describes hardening in similar themes: limiting access, containing possible damage, staying prepared and maintaining trusted backups.

The five-layer operating model

START WITH WHAT CAN FAIL

A threat model tells you which controls deserve priority.

List critical assets: administrator access, domain registration, hosting control panel, WordPress database, uploaded media, email, analytics, payment or affiliate accounts, DNS and backups. Then identify likely threats: stolen passwords, credential stuffing, vulnerable plugins, malicious uploads, accidental deletion, failed updates, compromised administrator devices, hosting failure and destructive malware.

Rank by impact × likelihood

A low-probability visual defacement is not automatically more important than losing domain control or every backup. Prioritize controls that protect the highest-value assets and the most plausible attack paths.

IDENTITY IS THE FIRST PERIMETER

Protect the domain registrar, hosting account, WordPress administrators and business email before polishing plugin settings.

If an attacker controls the registrar or primary email account, many WordPress-level controls can be bypassed through password resets, DNS changes or hosting access. Use unique accounts, current recovery information, separate administrator identities and MFA where supported. Do not share one administrator login across a team.

High-value accounts

• Domain registrar and DNS provider.
• Hosting control panel and cloud account.
• Primary email account used for recovery.
• WordPress Administrator accounts.
• Backup provider and storage account.
• Analytics, ad and payment accounts.

PASSWORDS ARE NOT ENOUGH

Require MFA for privileged accounts and design the recovery path as carefully as the login path.

OWASP recommends MFA wherever practical, especially for administrative and high-privilege users, because it significantly reduces password-only attack risk. Prefer phishing-resistant options when your provider supports them; TOTP authenticator apps are a practical baseline for many WordPress operators. SMS is better than password-only in many cases but carries additional risks such as SIM-swap and interception.

Recovery is part of MFA security

• Store recovery codes somewhere separate from the device used for MFA.
• Document who is allowed to reset MFA for team accounts.
• Require stronger verification for recovery than for normal support requests.
• Remove lost or old authenticators immediately.

UNIQUE CREDENTIALS

Use a password manager, long unique passwords and secure recovery addresses.

Reused passwords convert one unrelated breach into access to your website. A password manager makes unique credentials practical. Avoid sending administrator passwords through chat or email. Rotate credentials after suspected compromise, but do not rely on frequent arbitrary rotation as a substitute for MFA, uniqueness and breach response.

LIMIT BLAST RADIUS

Give each user only the permissions required for the job.

OWASP defines least privilege as assigning only the minimum permissions needed. In WordPress, a writer usually does not need Administrator. Use Editor, Author or custom capabilities when appropriate. Remove dormant users, contractors and integrations after the work ends. Separate publishing accounts from high-privilege maintenance accounts when the workflow supports it.

PATCH KNOWN WEAKNESSES

Keep WordPress core, themes and plugins current, but treat updates as controlled changes.

WordPress hardening guidance emphasizes staying current because security issues are fixed through releases. The correct workflow is not “never update” and not “blindly update everything.” Classify the change, ensure a recovery point exists, use staging for high-risk components, update, then verify critical journeys. Security releases should receive higher priority than cosmetic feature releases.

Update triage

• Urgent: actively exploited or security-critical component affecting your installation.
• High: security fix for an exposed plugin/theme or core path.
• Normal: regular maintenance update with low compatibility risk.
• Planned: major version or architectural change requiring staging and regression testing.

SUPPLY-CHAIN DISCIPLINE

Install themes and plugins only from trusted, maintained sources and remove what you no longer use.

WordPress specifically warns against untrusted plugins and themes. Pirated “nulled” software can contain malicious code and also blocks reliable updates. Before installing a component, review maintenance activity, compatibility, support history, permissions, frontend assets and whether the feature already exists elsewhere. Deactivated code can still remain on disk; remove components you no longer need after confirming they are not required for rollback.

Keep a component inventory, not just an Installed Plugins screen

For every material extension, record vendor/source, purpose, current owner, update channel, license/account dependency, data stored, external services contacted and what would break if the component were disabled. The inventory turns a supply-chain incident into a bounded investigation instead of a search through an unknown stack.

Provenance matters during recovery

After compromise, reinstalling from a random ZIP copied from an old laptop may reintroduce the same problem. Keep a reproducible list of trusted download sources and versions. Custom code should have version history and a known repository or protected source archive so a clean rebuild does not depend on files recovered from the compromised server.

WORDPRESS HARDENING

Hardening should reduce unnecessary entry points without creating brittle configurations.

Useful controls include keeping core updated, using secure file permissions, protecting wp-config.php, disabling the built-in theme/plugin file editor where operationally appropriate, restricting administrator access, using HTTPS and maintaining logs. Avoid “security through obscurity” claims such as assuming a renamed login URL or unusual table prefix makes a vulnerable site safe.

Disable dashboard code editing when your workflow does not require it

WordPress documents the DISALLOW_FILE_EDIT constant as a way to disable editing theme and plugin files from the administration interface. This can reduce one avenue for an attacker who already gained admin access, but it does not fix the underlying compromise.

PROTECT CONFIGURATION

Configuration files, secrets and writable directories need explicit ownership and permission rules.

Do not expose database credentials, API keys or private backups in public web directories. Keep file permissions no broader than required by the hosting environment. Avoid making the entire WordPress tree world-writable to solve one upload error. Store secrets in environment/configuration mechanisms supported by your host and rotate them after suspected exposure.

Inventory machine credentials as carefully as human accounts

Application passwords, SMTP credentials, payment keys, webhook secrets, backup tokens and API keys can retain access long after a human password changes. Record what each secret can do, where it is stored, which system owns it, when it was last rotated and how to revoke it. Use the narrowest permissions the integration supports.

Do not put recovery secrets inside the system they are meant to recover

If the only copy of a registrar recovery code, backup decryption key or hosting emergency credential lives in WordPress itself, a site compromise or deletion can remove the recovery path at the same time. Keep critical recovery material in a protected, independent location with access controls appropriate to the business.

BRUTE FORCE & CREDENTIAL STUFFING

Rate-limit abusive login attempts, require MFA and monitor repeated failures.

OWASP recommends login throttling and account-protection controls against password guessing. At WordPress level this can be implemented by a security layer, host, WAF or trusted plugin. Be careful with permanent lockouts that allow an attacker to deny service to legitimate users. Combine throttling with MFA, strong passwords and alerts for unusual administrator logins.

Do not mistake obscurity for authentication security

Changing the login URL may reduce noise from unsophisticated bots, but it does not make a stolen credential safe and it does not patch a vulnerable plugin. Treat hidden paths as an optional noise-reduction technique, never as the primary control. MFA, least privilege, throttling, patching and monitoring address stronger failure modes.

Separate abuse controls from account recovery

A rate-limit rule that blocks legitimate administrators during an incident can slow containment. Document how authorized operators can regain access without disabling protection for everyone, and test that path before an emergency.

SECURITY BELOW WORDPRESS

The host, PHP runtime, database and server configuration are part of the security boundary.

Keep supported PHP and database versions, understand how the host isolates accounts, verify malware scanning or WAF claims instead of assuming them, and know who is responsible for OS/security patches on managed versus self-managed infrastructure. On a VPS, responsibilities are broader than on managed WordPress hosting.

DOMAIN CONTROL

HTTPS protects traffic; domain and DNS account security protects where that traffic goes.

Use HTTPS sitewide, renew certificates automatically and fix mixed content. At the registrar, enable MFA and transfer lock where supported. Restrict DNS changes to authorized users. DNSSEC can provide DNS integrity protection when configured correctly, but changing DNS providers without coordinating DNSSEC can cause resolution failure, so treat it as an operational control rather than a checkbox.

COMPROMISE SIGNALS

Unexpected redirects, new administrators, modified files or spam pages are symptoms—not a diagnosis.

Other indicators include sudden outbound email, unknown cron jobs, injected JavaScript, SEO spam, changed DNS, altered payment/affiliate destinations or large unexplained traffic. Do not immediately delete random files before preserving logs and understanding scope. A compromised WordPress account may be only one part of a larger hosting or email compromise.

YOU CANNOT INVESTIGATE WHAT YOU NEVER RECORDED

Keep enough logs and monitoring to reconstruct important changes and failures.

Useful evidence may include web-server access/error logs, WordPress/PHP errors, security events, administrator/user changes, hosting activity, DNS changes, backup job status and uptime checks. Retention should be long enough to investigate delayed discovery. Protect logs from easy alteration by the same account that could compromise the website when practical.

Decide which events deserve durable audit history

At minimum, privileged login activity, user/role changes, plugin/theme installation, critical configuration changes, backup failures and domain/DNS changes should be attributable when the platform can provide that evidence. Avoid collecting sensitive data merely because logging is possible; logs themselves can become a privacy and security asset that requires access control and retention limits.

Time consistency makes evidence usable

Incident reconstruction becomes difficult when application, hosting and provider logs use different time zones or clocks. Record the timezone used by each major system and preserve original timestamps. During an incident, build a timeline instead of relying on memory.

BACKUP IS A RECOVERY CONTROL

A backup is valuable only when it contains the right data, is reachable during an incident and can be restored.

A robust strategy considers frequency, retention, scope, independence, encryption, integrity and restore testing. Current WordPress backup guidance treats database and files as separate parts that both need protection for a complete typical-site restore. NIST Cybersecurity Framework 2.0 adds an important recovery outcome: verify the integrity of backups and other restoration assets before using them for restoration.

The practical model

Frequency → Retention → Independence → Integrity → Restore test → Recovery runbook.

DEFINE ACCEPTABLE LOSS BEFORE THE INCIDENT

RPO describes acceptable data loss; RTO describes acceptable downtime.

If a store receives orders every hour, a weekly backup may violate the business RPO even though “backups exist.” If a brochure site can be offline for a day, the recovery process may be simpler. Define RPO and RTO per system, because database data, media, configuration and analytics may have different recovery needs.

These are examples, not universal targets. Define thresholds from your actual business impact.

BACK UP THE SYSTEM, NOT ONLY THE DATABASE

WordPress recovery usually needs both data and files.

• Database: posts, pages, settings, users and plugin data.
• wp-content/uploads: media and user-generated files.
• Themes and custom code.
• Plugin configuration or custom plugin files where not reproducible.
• Server/DNS configuration documentation.
• Secrets should be backed up securely, not copied into public archives.

Core files and public plugins can often be reinstalled from trusted sources, but custom code and configuration must be reproducible or backed up.

KEEP HISTORY

One rolling backup can preserve the compromise instead of the clean state.

If malware enters on Monday but is discovered two weeks later, seven daily backups may all be contaminated. Use tiered retention where justified—for example frequent recent copies plus weekly/monthly history. The exact policy should reflect change rate, storage cost, detection delay and compliance needs.

Protect at least some history from easy deletion

If your provider supports immutable, append-only or separately protected backup storage, it can reduce the risk that the same compromised account deletes both production and recovery history. Immutability is not a substitute for restore testing or access control; it is another failure-domain boundary. Where such features are unavailable, separate provider accounts and restricted backup credentials can still improve resilience.

AVOID ONE FAILURE DOMAIN

At least one recovery copy should not depend on the same hosting account or credentials as production.

If the hosting account is deleted, suspended or compromised, a backup stored only inside that account may disappear with it. Maintain an independent/off-site copy or provider boundary for critical sites. Protect backup accounts with separate credentials and MFA. Encryption helps confidentiality, but losing the decryption key makes the backup useless.

PROVE RECOVERY

A successful backup job is not the same as a successful restore.

Test restoration in staging or an isolated environment. Verify the database imports, media loads, permalinks work, users can authenticate, forms submit, scheduled tasks function and business-critical integrations are intact. Record restore duration and every manual step. NIST CSF 2.0 specifically calls for verifying backup/restoration-asset integrity before restoration and verifying the integrity of restored assets before normal operating status is confirmed.

Minimum restore evidence

• Date and backup set used.
• Restore destination.
• Time to functional service.
• Validation checklist results.
• Failures and remediation.

Test the dependencies outside WordPress too

A restored database and uploads folder can still produce a nonfunctional business if SMTP credentials, DNS records, payment webhooks, CDN configuration, object storage, scheduled jobs or third-party API secrets are missing. The recovery test should verify the complete critical journey, not only whether the homepage loads.

Record clean-state assumptions

For security recovery, document why the chosen restore point is believed to predate compromise and which components will be reinstalled from trusted sources instead of restored. A successful restore of a compromised component is still a failed recovery.

WHEN SOMETHING GOES WRONG

Contain first, preserve evidence, understand scope, eradicate the cause and recover from a trusted state.

1. Declare: identify the incident owner and affected systems.
2. Contain: restrict access, rotate exposed credentials and isolate compromised components where practical.
3. Preserve: save logs, suspicious files, timestamps and provider alerts before destructive cleanup.
4. Scope: determine whether email, hosting, domain, WordPress, database or user devices are involved.
5. Eradicate: remove malicious code/accounts and patch the entry point.
6. Recover: restore or rebuild from a known-good state.
7. Verify: test functionality, security controls and monitoring.
8. Review: document root cause, gaps and preventive changes.

NIST recovery guidance stresses planning, playbooks, testing and continuous improvement rather than improvising during an incident.

Prefer a clean rebuild when trust in the installation is lost

For a serious compromise, manually deleting files until scanners become quiet may leave persistence behind. A safer path can be to provision clean infrastructure, install WordPress core and third-party components from trusted sources, restore only validated data/content, rotate credentials and then verify before traffic returns. Which path is appropriate depends on scope, evidence and operational complexity.

Define communication and escalation before the incident

Know who contacts the host, registrar, payment provider, customers or legal/security professionals if personal data, payments or other regulated information may be affected. This module does not define jurisdiction-specific notification law; it defines the operational requirement to identify that decision owner before an incident forces the question.

COMPROMISED WORDPRESS PLAYBOOK

Do not restore a backup and assume the incident is closed.

If the attacker still controls the administrator email, hosting account, vulnerable plugin or stolen credential, the restored site can be compromised again. Check account access, rotate secrets, update vulnerable components, remove unknown users, replace core/plugin/theme files from trusted sources when appropriate, inspect database content and verify DNS/domain integrity. If payment or personal data may be involved, escalate to qualified security/legal professionals and follow applicable notification obligations.

RECOVERY RUNBOOK

A disaster-recovery plan should be executable by someone under pressure.

Document where backups live, who has access, domain/hosting contacts, recovery credentials, restore order, DNS steps, validation tests and communication responsibilities. Keep a protected copy outside the production site. Test it periodically and after major architecture changes.

Recommended restoration order

1. Secure administrator identity and provider accounts.
2. Provision or verify clean infrastructure.
3. Restore database and required files.
4. Apply current safe configuration and patches.
5. Restore DNS/HTTPS if infrastructure changed.
6. Test user journeys and integrations.
7. Re-enable traffic carefully.
8. Monitor for recurrence.

AUDIT IN THE RIGHT ORDER

A professional security audit prioritizes control gaps that can cause real compromise or unrecoverable loss.

1. Inventory assets and administrator accounts.
2. Review domain, hosting and email MFA/recovery.
3. Review WordPress roles and dormant users.
4. Inventory core, themes, plugins and update status.
5. Check trusted source and maintenance status.
6. Review file/configuration exposure and HTTPS.
7. Review login protection and monitoring.
8. Document backup frequency, retention and independence.
9. Perform or review a restore test.
10. Review incident/recovery runbook and escalation contacts.
11. Prioritize findings by exploitability, impact and recoverability.

Severity model

• P0: active compromise, exposed secret, no recoverable backup, lost domain/hosting control.
• P1: high-privilege account without MFA, known vulnerable exposed component, untested single backup path.
• P2: hardening, monitoring or workflow weakness with meaningful but lower immediate risk.
• P3: documentation and polish improvements.

FAILURE-FIRST SECURITY

Every security control can create operational failure if implemented without recovery planning.

• MFA without recovery can lock out the owner.
• A WAF can block real customers or APIs.
• Overly restrictive file permissions can break updates/uploads.
• Automatic updates can introduce compatibility failure.
• Backup encryption without key management can make restores impossible.
• DNSSEC misconfiguration can make the domain unreachable.
• Restoring an old database can overwrite newer legitimate orders or users.

Before each high-impact control, define rollback, owner, validation and recovery.

30-DAY IMPLEMENTATION

Build security in layers instead of trying to deploy every control at once.

Week 1 — identity and inventory

• Inventory domain, hosting, WordPress and email administrators.
• Enable MFA and fix recovery methods.
• Remove dormant accounts and unused plugins/themes.
• Record current versions and backup locations.

Week 2 — hardening and updates

• Patch core/components using staging where appropriate.
• Review file/configuration exposure.
• Set login throttling/WAF policy if needed.
• Verify HTTPS and domain protections.

Week 3 — backup and recovery

• Define RPO/RTO.
• Create independent backup copies and retention.
• Run a full restore test.
• Document restore duration and gaps.

Week 4 — detection and incident readiness

• Configure uptime/error/security monitoring.
• Define incident owner and escalation contacts.
• Write a one-page response/recovery runbook.
• Run a tabletop compromise exercise.

PRACTICE

Complete these exercises before moving to monetization.

Exercise 1 — privileged-account map

List every account capable of changing the site, DNS, backups or administrator email. Record owner, MFA state, recovery method and last review date. Remove or downgrade unnecessary access.

Exercise 2 — threat model

Choose five critical assets and five plausible threats. Score impact and likelihood, then map one preventive and one recovery control to each.

Exercise 3 — restore drill

Restore a recent backup into staging. Time the process and verify login, media, forms, links and business-critical functions. Record every missing step.

Exercise 4 — compromise tabletop

Assume an administrator account and one plugin are compromised. Write the exact containment, evidence, credential, rebuild/restore and verification steps.

Exercise 5 — 90-second emergency card

Create a short emergency checklist containing hosting contact, registrar contact, backup location, incident owner, account-lockdown steps and where the full runbook lives.