This is what it does
Try it
A default WordPress site tells a stranger the administrator’s login name. This is the drop-in file that takes that surface away — pick the requests a stranger could send and read what it answers.
The file’s own rules, run in your browser — no WordPress install involved
- What it does: for logged-out callers it unregisters every REST route under
/wp/v2/users— the collection, the per-id form, the “me” form and application passwords — and it answers author archives with a 404. Signed-in administrators see no change. - What to try: tick the query-string form of the user call and watch it get the same verdict as the path form, then switch to “signed in as an administrator” and watch every verdict return to stock WordPress.
- What it runs on: a port of the file’s two rules. The product is a PHP file that runs inside WordPress, so it cannot execute in a page; this re-implements its two hooks exactly and cites them. No site is contacted.
- What it does not do yet: comments, oEmbed and the core user sitemap are outside the file and stay outside the verdict — marked as not covered rather than quietly passing.
Status
Where this actually stands today
- It is deployed. The file was uploaded, linted on the server, and moved into the must-use plugin directory of the studio’s own WordPress site, where it loads on every request with no activation step.
- It was verified from outside after it went live. The public user route no longer appears in the REST index while the posts route still does, and the home page, the shop, the login page and an ordinary post endpoint all still answer.
- The file is 53 lines. Its scope is the user routes and author archives; that is the whole of it.
- The honest limit is scope, not correctness. Comments, oEmbed responses and the core user sitemap may still expose a display name. Those are the next surfaces, and this file does not claim them.
The numbers
Constants from the build
53lines in the file, covering the user routes and author archives
125 KBthe author archive page that rendered the login name before the fix
2layers kept: request-string rules for probes, and route removal at the API
0settings screens, because there is nothing to configure
Under the hood
What it is built on
- Stack
- One PHP file added to a WordPress install. No build step, no dependency, no theme change.
- Surfaces
- The REST user route family and the author archive, both only as they appear to logged-out callers. There is no admin screen and no setting anywhere in it.
- Runs where
- The must-use plugin directory of a WordPress installation, where it loads on every request without activation.
- Data
- None. The file reads no data, stores nothing and adds no table.
- Payments
- None. It was written for the studio’s own site and is not sold.
- Tested by
- The server’s PHP linter before installation, then an external probe after it went live: user route absent from the REST index, posts route present, and the home, shop, login and ordinary post surfaces still answering.
Plainly
What this is not
- It closes one enumeration path. It is not a complete answer and it does not make a WordPress site secure.
- It is not a firewall and it does not filter traffic. It removes API surface so there is nothing to answer for logged-out visitors.
- It is not a fix for comment exposure, oEmbed or the user sitemap, all of which sit outside its scope.
- It does not replace the fundamentals — strong unique passwords, two-factor on administrator accounts, current core and plugins, and a backup you have restored at least once. It touches none of those.
- There is nothing to configure. It has no settings screen and no admin page, which is also why there is nothing to get wrong after installation.
Questions about WordPress Hardening
Which surfaces a default install exposes, or what this deliberately leaves alone — ask, and expect a straight answer about the parts it does not cover.