WordPress REST API Security: What’s Exposed by Default

The WordPress REST API has been enabled by default on every install since WordPress 4.7, back in December 2016 — which means most site owners have never actually turned it on, decided to use it, or checked what it exposes. It’s just there, quietly, and one of its earliest default behaviors is still worth understanding even though it was partially fixed years ago.

What actually happened, and what got fixed

When the REST API first shipped enabled by default in WordPress 4.7, an early version of it fully exposed user data through the /wp-json/wp/v2/users endpoint — unauthenticated, meaning anyone, without logging in, could query that endpoint and retrieve information about registered users on the site, including usernames. That’s directly useful information for an attacker attempting credential-stuffing or brute-force login attempts, since knowing a valid username is half of what’s needed.

WordPress 4.7.1, released in January 2017, restricted that endpoint specifically to reduce this enumeration exposure. That’s a meaningful, real security improvement — but it’s worth being precise about what it actually changed versus what it didn’t fully close off. Some degree of user enumeration remains possible on many WordPress sites through other default vectors that weren’t part of that specific 4.7.1 fix, including author archive URLs (/?author=1 style requests, which redirect to the author’s public archive page and reveal their username in the resulting URL) and login-page error message differences between “unknown username” and “wrong password.”

The 4.7.1 fix addressed one specific endpoint’s unauthenticated data exposure. It didn’t eliminate user enumeration on WordPress generally — that remains a broader, ongoing hardening consideration, not a solved problem from one patch nearly a decade ago.

Why this still matters years later

Username enumeration on its own isn’t a breach — it doesn’t hand over a password. But it removes one layer of obscurity that a brute-force or credential-stuffing attack otherwise has to work through, and it’s exactly the kind of low-effort reconnaissance step automated attack tools are built to perform at scale, across huge numbers of WordPress sites simultaneously, without any specific targeting involved. Given how much of the WordPress vulnerability landscape (covered in the broader 2025 plugin vulnerability data) involves automated, opportunistic exploitation rather than targeted attacks, removing easy reconnaissance vectors is a genuinely worthwhile hardening step, even if it’s not glamorous.

What’s actually exposed by a default WordPress install today

Beyond the users endpoint specifically, it’s worth knowing the REST API exposes a fair amount by default, by design — because a lot of that data is meant to be public:

• Published post and page content — expected and generally fine, since this content is public on your site anyway through normal browsing.
• Post and page metadata, depending on your specific plugin configuration — some plugins register custom fields as visible through the REST API without it being obvious that they’ve done so.
• Author display names and, depending on configuration, usernames — the specific issue partially addressed in 4.7.1, with the caveats above about remaining enumeration vectors elsewhere.
• Site metadata — general information about the site’s configuration, generally low-risk but worth being aware is queryable.

Why this is a good example of defense in depth

The REST API’s enumeration history is a useful small case study in a broader security principle worth internalizing: no single fix closes off a whole category of risk permanently, because attackers and researchers keep finding adjacent paths to the same information. The 4.7.1 patch closed one specific endpoint; author archive URLs and login error messages remained as parallel routes to similar information, and neither was part of that original fix. The practical lesson isn’t that the 4.7.1 patch failed — it succeeded at exactly what it targeted — it’s that treating any single patch as having “solved” a category of risk, rather than addressed one specific instance of it, tends to leave the adjacent paths unexamined indefinitely.

What’s actually worth doing about this

1. Use a distinct display name, separate from your login username, for any user account with elevated privileges — this alone closes off a large share of the practical risk from author-archive-based username enumeration, since the exposed name and the actual login credential no longer match.
2. Consider restricting REST API access for unauthenticated requests if your site doesn’t rely on the API being publicly queryable — plenty of standard WordPress sites never need external, unauthenticated REST API access at all, and a security plugin or a few lines of custom code can restrict it appropriately without breaking normal site functionality.
3. Enforce strong, unique passwords and two-factor authentication regardless of enumeration exposure — this addresses the actual attack (credential guessing) rather than just one piece of reconnaissance that feeds into it.
4. Periodically check what your installed plugins are exposing through the REST API — particularly any plugin handling forms, membership data, or custom post types, since not every plugin developer treats REST API exposure as carefully as WordPress core does.

None of this is exotic security advice — it’s genuinely basic hardening. But “basic” and “commonly done” aren’t the same thing, and the REST API’s default-on nature since 2016 means a lot of sites are running with more exposure than their owners realize, simply because nobody ever made an active decision about it one way or the other.

A balance worth keeping in mind before locking things down aggressively

It’s worth resisting the urge to disable the REST API entirely without checking what depends on it first. A growing number of legitimate features rely on it directly — the block editor itself communicates with WordPress through REST API calls, as do many modern plugins, mobile apps connecting to a WordPress backend, and any headless or Jamstack-style setup by definition. Blocking unauthenticated access to specific sensitive endpoints (like the users endpoint) is a fundamentally different, much safer action than disabling the REST API wholesale, which can quietly break core editing functionality if done carelessly. The goal is narrowing exposure of genuinely sensitive data, not treating the API itself as the threat.