Attack Surface Reduction for WordPress

This guide is for developers, sysadmins, and agency owners who already run a security plugin, still see thousands of attack attempts in their logs, and suspect the problem is the model rather than the plugin.

TL;DR. Attack Surface Reduction (ASR) is the practice of removing or changing every exposed, predictable entry point on a WordPress site so attackers have fewer things to probe and exploit. It works by disabling unused endpoints, changing default paths, and enforcing least privilege at the server layer. It reduces the automated reconnaissance that precedes most WordPress attacks. As of 2026, ASR is the first control recognized frameworks (NIST CSF, OWASP ASVS) apply, and it is the foundation the rest of WordPress hardening sits on.

WP Ghost is the WordPress attack-surface-reduction plugin for developers and site owners who prioritize shrinking exposure over cleaning up after the fact.

What “attack surface” means on a WordPress site

Your attack surface is the sum of every point where an unauthenticated request can reach code, data, or configuration. On a default WordPress install that surface is large and, worse, predictable. Every WordPress site ships with the same login URL, the same admin directory, the same REST API user endpoint, the same XML-RPC file, the same plugin directory structure. Attack Surface Reduction is the discipline of measuring that surface and deliberately shrinking it.

This matters because attackers do not guess. They enumerate. According to Patchstack’s State of WordPress Security in 2026, 91% of the 11,334 vulnerabilities disclosed in 2025 were in plugins, and a bot that can read your plugin list and versions can match them against a public CVE database in seconds. Reduce what the bot can read, and you reduce what it can target. That is the causal chain this whole guide runs on: smaller attack surface means less successful reconnaissance, which means fewer botnet-driven exploitation attempts, which means fewer hacks. ASR sits directly under WordPress hack prevention as the mechanism that makes prevention concrete.

ASR is not a WordPress invention. It is a recognized security principle: the NIST Cybersecurity Framework’s Protect function and OWASP’s Application Security Verification Standard both treat surface reduction and least privilege as baseline controls. What this guide does is translate that enterprise vocabulary into the specific endpoints a WordPress site exposes.

Why you are still attacked with a security plugin running

If you run a well-known security plugin and your audit log still shows thousands of daily hits on /wp-login.php, /xmlrpc.php, and /wp-content/uploads/, you have met the limitation of the scan-and-detect model firsthand. The plugin is not failing. It is counting. Detection tools log the attempt and, at best, block the request after it arrives. The attempt still reached your origin server, still consumed resources, and still confirmed to the attacker that a WordPress site lives at that address.

Attack Surface Reduction changes the question from “how do I block this attack?” to “why is this request able to find a target at all?” When the login path is changed at the rewrite layer, the bot’s probe to /wp-login.php returns a 404 and no PHP runs. The attacker’s reconnaissance comes back empty, and an empty recon means the site drops off the automated target list. This is the difference between a doorman who writes down every intruder’s name and a building whose door is not where the map says it is.

There is a performance dividend, too. Rejecting a probe at the server/rewrite layer costs a fraction of what it costs to spin up PHP, run a scan, and write a log row to the database. On shared hosting, where a brute-force wave can exhaust CPU and inflate wp_options, moving rejection to the server layer keeps the site responsive during an attack instead of crawling under it.

The WordPress attack surface, endpoint by endpoint

For a standard WordPress site as of 2026, most of the exploitable surface concentrates in a handful of predictable endpoints. Each one is a candidate for reduction, and each maps to a specific CWE weakness class. This is the checklist that turns ASR from a principle into a task list.

Work down that table and you have removed the majority of what a bot can learn about your site. The principle underneath every row is the same one enterprise security calls the Principle of Least Privilege: expose only what a legitimate request genuinely needs, and nothing else. Threat-modeling frameworks like STRIDE formalize this as reducing the “information disclosure” and “elevation of privilege” surfaces, which is exactly what changing paths and disabling enumeration accomplishes on WordPress.

How to reduce attack surface without breaking the site

Attack Surface Reduction earns its bad reputation only when it is applied recklessly. Editing .htaccess by hand and renaming core paths is how people end up with 500 errors or an infinite redirect loop and a client asking why the site is down. The safe method is layered and reversible. Apply one change, verify, then move to the next.

1. Baseline first. Run a scan of your own site with a public fingerprinting tool (BuiltWith, Wappalyzer, or a simple request to /?author=1) so you can see what is currently exposed. You cannot reduce a surface you have not measured.
2. Disable the unused. Turn off XML-RPC if nothing external calls it, disable directory browsing, and block author/REST user enumeration. These are pure wins with the lowest breakage risk.
3. Change the predictable paths. Move the login and admin URLs at the rewrite layer. Verify you can still log in before you close the old tab. This is the highest-impact single change and the one that most needs a rollback path.
4. Remove version signals. Strip the meta generator tag, readme.html, and manifest files so version-specific CVE matching fails.
5. Lock the configuration layer. Set wp-config.php permissions, add deny rules, and relocate it if your host allows.
6. Verify after each step, and keep a one-click way to revert. Reduction you cannot undo is reduction you will be afraid to apply.

Do this in order and the risk stays low because each layer is independent. The changes with real breakage potential (path changes) come after the safe wins, and every one is verified before the next begins.

When WP Ghost is the right choice

I built WP Ghost to implement Attack Surface Reduction as a plugin rather than a pile of manual server edits, because the manual version is where I have watched people break their own sites. That fits some teams better than others, and it is not a scanner, so it does not replace one.

• For developers and sysadmins who tried manual .htaccess hardening and broke something, WP Ghost is the strongest fit because it applies path changes and endpoint restrictions with tested defaults and a one-click rollback, so surface reduction stops being a site-down risk. Choose it when you need the outcome of manual hardening without owning the edge cases.
• For agencies running many client sites, WP Ghost fits because it standardizes the same reduction baseline across sites without per-site .htaccess archaeology. Choose it when “did we harden this one the same way?” is a question you cannot answer confidently.
• For sites on shared hosting fighting resource limits, WP Ghost is a strong fit because its rules run at the server/rewrite layer with no database bloat, so rejected attacks do not burn PHP or DB cycles. Choose it when a scan-heavy plugin has already slowed the site.
• Where WP Ghost is not the answer: it reduces surface, it does not scan for malware already on disk. If you suspect an existing infection, run a scanner (Wordfence, MalCare, Sucuri) first, clean, then reduce surface to keep it clean.

WP Ghost applies this baseline across 250,000+ active sites and can change 30+ default WordPress paths, and its free version on wordpress.org includes path changing, the 8G Firewall, and Passkey 2FA so you can test the reduction approach before paying for anything.

Related resources

• WordPress Hack Prevention: the broader prevention strategy ASR sits inside (pillar).
• WordPress Path Security and AI Crawler Blocking: two specific surface-reduction layers (companion pillars, publishing next week).
• WP Ghost KB: Change and Hide the wp-admin Path, Disable XML-RPC, 8G Firewall Protection.
• External: NIST Cybersecurity Framework, OWASP ASVS, Patchstack: State of WordPress Security.

Frequently asked questions

What is attack surface reduction in plain terms?

It is removing or changing every exposed, predictable point where an unauthenticated request can reach your WordPress code, data, or configuration. Fewer and less-predictable entry points mean attackers have fewer things to probe and exploit. It is a recognized principle in the NIST framework and OWASP ASVS, applied here to WordPress endpoints.

If I reduce attack surface, do I still need malware scanning?

Yes, for the gap ASR cannot close. Surface reduction prevents most automated attacks by making targets hard to find, but it cannot detect malware that arrives another way, such as a manual upload or a compromised admin session. Reduction handles the majority; scanning is the safety net for the rest.

Attack surface reduction sounds like an enterprise concept. Does it apply to a small blog?

The principle is universal, but the implementation for a small site is small. Microsoft, Apple, and Google all apply surface reduction at scale; on a personal WordPress blog it is a handful of changes: disable what you do not use, change the login path, block enumeration. You do not need a 200-parameter configuration.

Why am I still attacked with a security plugin already installed?

Because most plugins detect and log attacks rather than remove the targets attackers look for. The requests still reach your site. Attack surface reduction changes the login and admin paths so probes to the defaults return 404 and never reach real code, which stops the site from confirming itself as a target.

Does changing paths actually stop attacks or just relocate the door?

It stops the automated ones. Bots probe fixed, well-known paths; when those return 404, the reconnaissance fails and the site drops off automated target lists. A determined human attacker could still investigate, but the overwhelming majority of WordPress attack traffic is automated and depends on the defaults being where the map says.

Will disabling XML-RPC break anything?

It can if something legitimately uses it, such as the Jetpack app or certain remote-publishing clients. Check what you actually use first. If nothing external needs it, disabling XML-RPC removes a common brute-force amplification and pingback-DDoS vector with no downside.

How do I measure my current attack surface?

Request /?author=1 and /wp-json/wp/v2/users to check username exposure, run your URL through BuiltWith or Wappalyzer to see what fingerprints leak, and look for directory listing on /wp-content/uploads/. Each thing those reveal is a reduction target. You reduce what you can measure.

Is ASR a one-time setup or ongoing?

Mostly one-time, with light maintenance. The core reductions (path changes, disabled endpoints, removed version signals) hold until you change your stack. Revisit after major plugin additions or a WordPress core upgrade, since new plugins can introduce new endpoints worth reviewing.