WordPress Security: The Basics I Actually Enforce

Why WordPress gets hit

WordPress powers a huge share of the web. Attackers automate against it because the ROI is good: outdated plugins, weak admin passwords, and abandoned themes are still common. That does not mean WordPress is unusable—it means you treat it like a production system, not a toy install.

Hardening checklist I actually enforce

1. Updates: Keep core, themes, and plugins current—or remove what you do not need.
2. Least plugins: Every plugin is code you did not write. Prefer well-known, actively maintained plugins.
3. Auth: Strong unique admin passwords + 2FA; limit login attempts; do not use admin as the username.
4. TLS: HTTPS everywhere; HSTS at the edge when ready.
5. Backups: Automated, tested restores, offsite copies.
6. File permissions: Sensible ownership; no world-writable config.
7. Disable leftovers: Unused XML-RPC, demo content, unused themes.
8. Hosting: Reputable host with WAF/malware scanning options for public sites.
9. Principle of least privilege: DB user is not root; SFTP users are scoped.

WordPress security handbook is a solid baseline: Hardening WordPress.

Plugins are the supply chain

Same mental model as Composer/npm: fewer dependencies, better odds. Delete abandoned plugins. Review changelog and last-updated dates before installing something that touches auth, payments, or file uploads.

Follow-along: new site baseline

1. Install on trusted hosting with automatic backups enabled.
2. Create a non-admin administrator; enable 2FA.
3. Install only required plugins; delete default themes you will not use.
4. Force HTTPS; set strong salts/keys in wp-config.php (generator from wordpress.org).
5. Schedule weekly update review + monthly restore test.

When I recommend leaving WordPress

If the site is really an app with custom workflows, auth rules, and APIs, I would rather build it in Laravel. WordPress is fine for content-heavy marketing sites when you lock it down. It is a poor default for complex product backends.

Troubleshooting and common mistakes

Most failures I see are configuration and process issues, not “the framework is broken.” Slow down: reproduce on a clean environment, read the exact error, and change one variable at a time.

• Confirm you are on the documented major version of the tool you are following.
• Prefer official docs over random outdated blog snippets when commands disagree.
• Keep lockfiles committed so teammates and CI install the same dependency graph.
• Separate “works on my machine” fixes (PATH, SDK licenses, local services) from application bugs.

What to do next

Implement the smallest vertical slice from this article on a throwaway branch, then promote the patterns into your real app. Guides that stay theoretical never catch the auth, env, and deploy footguns that actually burn time.

Incident response basics

1. Take the site into maintenance / offline if actively exploited
2. Preserve logs and a forensic copy before mass deletes
3. Rotate all admin passwords, salts, and hosting/FTP credentials
4. Restore from a known-good backup if integrity is uncertain
5. Patch the entry point (plugin/theme/core) before reopening

If you cannot confidently verify integrity, restore beats “cleaning malware by hand” on a public marketing site.

Hosting decisions that matter more than plugins

Cheap shared hosting with outdated PHP and no isolation is a larger risk than whether you installed one more security plugin. Prefer hosts that keep PHP current, isolate accounts, and offer malware scanning / WAF options for WordPress.