What this guide covers
The short answer, and where hardening lives
Hardening is configuration, not detection. A firewall and a malware scanner watch for something happening. Hardening removes the path it would happen down in the first place.
Six categories make up the stack: patching, file and database permissions, administrative surface, response headers, obscurity measures, and the operational layer that keeps the rest true after a release goes out. Patching lives at the plugin, theme and core level. Permissions live on the server and in the database. The file editor and two-factor authentication live on the admin screens, and response headers get sent by the server or a proxy. A plugin cannot set a file permission or send a header the way a server configuration can.
A plugin reaches only the WordPress band
Server
- File and directory permissions
- Response headers
- wp-config.php protection
Database
- Reduced database privileges
- Authentication keys and salts
WordPress
- File editor disabled
- Two-factor authentication
No figures needed here. This is a grouping of measures by where each is configured, not a severity ranking.
Read what ongoing WordPress security work covers once you know which of the six you actually own.
List which of the six categories you can currently point at a real setting for, not a plugin dashboard toggle. The ones you cannot name are the gap this piece is about.
How the layers actually work
File permissions
Directories 755/750, files 644/640, wp-config.php 440/400 on suexec
File editor disabled
One line in wp-config.php closes the in-browser edit path
Database and keys
Reduced privileges, rotatable authentication keys and salts
File and directory permissions
WordPress core, wp-admin and wp-includes should be writable only by your user account. wp-content is the exception, since plugins, themes, uploads and cache write there. The handbook gives permissions as ranges, not one number: directories at 755 or 750, files at 644 or 640, and wp-config.php at 440 or 400 on a suexec setup.
Which number is correct depends on your host. On suexec or PHP-FPM, the PHP process runs as the file owner and can use the tighter number; on a shared mod_php setup, the web server’s own user needs write access, so the same tight number breaks the site. wp-config.php gets the strictest rule, holding the database credentials and the four secret authentication keys, and the handbook calls a default 644 permission on it a hazard.
The file editor, and why it goes first
Setting DISALLOW_FILE_EDIT to true in wp-config.php removes the plugin and theme editor from wp-admin, equivalent to removing the edit_themes, edit_plugins and edit_files capabilities from every user. Without it, an attacker holding an admin session can paste a PHP web shell straight into a theme file through the browser, no upload needed. Removing the editor closes that path.
Database privileges and authentication keys
Day to day, WordPress needs only SELECT, INSERT, UPDATE and DELETE from its database user. DROP, ALTER and GRANT can be revoked without breaking anything WordPress normally does, so an injection flaw in an unpatched plugin cannot drop a table or create a privileged user, even if it succeeds.
The keys and salts sign your authentication cookies. If they are weak, default or leaked, someone holding them can forge a valid login cookie without your password, and rotating them ends every logged in session at once, the fastest way to remove a session you do not control.
Read the three plans and what each covers if you’d rather have someone else run this. See the three plans.
After each change, load the site, log in, upload a media file and save a post. Those four actions confirm permissions, sessions and write access at once, so you know within a minute whether the tighter setting broke something.
Security headers, including the one to stop maintaining
The headers worth setting
- Content-Security-Policy tells the browser which sources may load or execute. A policy that disallows unsafe-inline means an injected script tag does not run.
- X-Frame-Options stops the page loading inside a frame on another domain, the mechanism behind clickjacking.
- X-Content-Type-Options: nosniff stops the browser guessing a file’s type instead of trusting the declared type.
- Strict-Transport-Security tells the browser to only connect over HTTPS for the stated period.
- Referrer-Policy and Permissions-Policy limit what leaks to other origins and which browser features a page may use.
X-XSS-Protection, and why guides still list it
MDN, the reference most browser vendors defer to, marks this header both deprecated and non-standard. It “was a feature of Internet Explorer, Chrome and Safari that stopped pages from loading when they detected reflected cross-site scripting (XSS) attacks.” Chrome and Edge have since removed the XSS auditor the header controlled, so setting it today changes nothing.
MDN’s own guidance is direct: “it is recommended that you use Content-Security-Policy instead of XSS filtering.” It warns that in some cases the header “can create XSS vulnerabilities in otherwise safe websites,” which makes it a header that can work against you.
The honest answer to what people are searching for is this. Do not tune this header. Retire it, and put the effort into Content-Security-Policy, which is harder to get right and is the one doing the actual work.
| Header | What it does | Status |
|---|---|---|
| Content-Security-Policy | Tells the browser which sources may load or execute | Set it, does the actual work |
| X-Frame-Options | Stops the page loading inside a frame on another domain | Set it, stops clickjacking |
| X-Content-Type-Options | Stops the browser guessing a file’s type instead of trusting the declared type | Set it, stops MIME sniffing |
| Strict-Transport-Security | Tells the browser to only connect over HTTPS for a stated period | Set it, forces HTTPS |
| Referrer-Policy | Limits what leaks to other origins on navigation | Set it, limits leakage |
| Permissions-Policy | Limits which browser features a page may use | Set it, limits feature access |
| X-XSS-Protection | Once stopped some browsers loading pages with detected reflected XSS | Deprecated per MDN, retire it |
Status described in words, not header syntax to copy. No HSTS max-age value shown, since that number is sourced only to a secondary vendor article.
Read about how response headers and caching are handled for performance if headers are new territory for you.
Request your own home page and read the response headers back. Then check a page that loads a third party script or embed, since a policy that passes cleanly on the home page often blocks something the moment an embed is involved.
What good looks like
The configuration is set, and somebody can say when each item was last checked. Updates are applied on a schedule, tested before going live, and reversible if one breaks something. That is ordinary practice offered by several providers, not something unique to any one of them. The plugin inventory is short, and every item on it is still maintained upstream.
Patchstack, a vendor that sells a vulnerability monitoring product, published figures worth reading with that in mind:
| Layer | Share of 2025 disclosures |
|---|---|
| Plugins | Roughly 91 percent |
| Themes | Roughly 9 percent |
| Core | 6 vulnerabilities, out of 11,334 total |
Read how updates get tested before they go live once you know the plugin layer is where the exposure actually sits.
Pick the three most recently updated plugins on your site and find out who applied each update and whether anything was checked afterward. If you cannot answer either question, that is the gap.
What to do about it
In order of what returns most for the effort:
Audit your plugins and themes and remove what is not used.
Disable the file editor, one line in wp-config.php.
Tighten wp-config.php permissions, then the directories, testing after each.
Set the current header set, and remove X-XSS-Protection if it is there.
Reduce the database user’s privileges and rotate the keys.
Decide who applies and tests updates, and on what cadence.
After each change above, run the same four checks from the permissions section again: load the site, log in, upload a media file, save a post. A hardening change you cannot confirm is a change you are trusting rather than one you have made.
Would rather not run this list yourself?
See what hardening is included in NoDrama’s WordPress security retainer.
Common misconceptions
“A security plugin is hardening.”
It firewalls, scans and limits login attempts: detection, not configuration.
“Changing the table prefix and admin username secures the site.”
The handbook frames this as obscurity, stopping scripted attacks rather than a targeted one. Cheap and worth doing, not a defense on its own.
“Core updates are the priority.”
6 of the 11,334 vulnerabilities disclosed in 2025 were in core, and core auto-updates already cover most of that.
“My host handles security.”
Hosting-level protection is a different layer from the application-level configuration described here.
What this does not cover
The exact permission numbers for your host, which depend on how it runs PHP. Writing a Content-Security-Policy for your specific third party scripts. Incident response and cleanup after a compromise. And no formal certification: hardening supports compliance work, not a compliant status.
Where this leaves your site
Hardening is a stack of configuration changes, most of it living outside WordPress itself: the server, the database, the response headers. It holds only as long as somebody keeps patching the layer where the vulnerabilities actually are, plugins rather than core.