English
Deutsch
PolskiWhich WordPress Data Is Public: Understanding REST API Access and Permissions
Management Summary
The WordPress REST API is a connection through which applications read or change website data. It supports editing and integrations, so a long public list of available routes is not automatically evidence of a security problem. The important distinction is between knowing that an operation exists and having permission to perform it. The example of 203 listed routes shows why public content and protected actions need different treatment. Hiding the list does not secure access, while disabling everything can disrupt useful website functions.
Contents
The WordPress REST API is an interface through which programs request or change website data. It exposes structured data for the block editor, apps and integrations. An API index can list hundreds of routes without granting anonymous access to every operation. Route visibility, returned fields and permission checks are separate questions.
Finding and interpreting the index
REST content endpoints became part of WordPress core in version 4.7, released in December 2016. The usual root is /wp-json/ relative to the WordPress site, for example /blog/wp-json/. Without pretty permalinks, ?rest_route=/ can provide the index. The page’s API discovery link identifies the configured root. Plugins, filters or server rules can change access.
A route is a URL pattern. An endpoint combines a route with an operation such as GET or POST. A listed POST method is not evidence that unauthenticated publishing is possible: authorization runs separately. Some routes may also be omitted from discovery. The index is an inventory aid, not a complete security audit.
The historical 203-route example
The saved measurement for this site’s blog, dated 6 September 2026, records 203 routes and ten namespaces. The entries include 110 routes assigned to wp/v2 and 59 to yoast/v1. The namespace subtotals sum to 202, one fewer than the overall count. The overall route count and namespace subtotals therefore use different scopes in this saved summary.
These are installation-specific counts at a recorded time, not a WordPress default or a current measurement. Even wp/v2 is not exclusively core: custom content types can add routes there. A namespace such as vendor/v1 identifies an API family and version; v1 is not the installed plugin’s release version.
The same snapshot records successful GET responses for posts, pages, media, comments, types and search, 401 for settings, plugins and themes, and 404 for the users collection. These observations apply to the tested requests. They do not establish the permissions of every method, record or field.
Public content is not every stored field
For ordinary public posts, the API can return article HTML in content.rendered as well as a separate excerpt. That is not the complete themed page: navigation and layout are separate, and rendering filters can affect the content. A response size alone does not establish completeness.
Drafts, private posts, password-protected content and editing fields have separate rules. Custom types require REST support, and plugins can modify permissions or representations. A claim that everything published anywhere on the site is available through one standard post request is too broad.
Namespaces provide clues, not a full plugin inventory
A distinctive namespace can indicate a component, but not every active plugin registers REST routes. Themes and custom code can register routes, and one component can use several namespaces. The index therefore neither lists every installed plugin nor proves exact versions or vulnerabilities. Asset paths and version parameters can provide additional clues, but may be rewritten or use unrelated cache versions.
For site administration, the reliable inventory comes from installed components and their actual versions. Unneeded active components deserve review; an unfamiliar namespace alone does not establish that a component is unused.
200, 401, 403 and 404 need context
A 200 may contain an empty collection or intentionally public data. A 401 generally indicates an authentication problem; 403 indicates refusal. Neither code proves that a particular account or private record exists. A 404 may reflect a missing route, missing object, policy decision or upstream response. Status, response body, method and configuration need joint interpretation.
Removing an unused route can reduce exposure, but 404 is not inherently a better authorization control. A hidden index does not disable the underlying endpoints. Broad API shutdowns can break the block editor and integrations. Required endpoints need explicit permission checks and tests for permitted and denied operations.
Author identity is not automatically a login name
The core user schema distinguishes public display name name, public author slug, and login username, which belongs to the editing context. Without user-list privileges, the standard collection is generally limited to authors with published posts in REST-enabled types. A successful collection response is not a list of all accounts.
The author slug can derive from the login during creation, but a supplied value, sanitization, filters and collision suffixes can change the result. Display name, slug and login can coincide without being identical by definition. Public identity is not a password and should not be treated as the main authentication secret.
A practical review
A review records the discovered root, timestamp and route inventory, then compares representative public responses with the intended publication policy. Sensitive operations require separate capability tests, including an anonymous request and a low-privilege account in a controlled test environment. Reading a route list does not exercise write permissions.
Strong unique passwords, appropriate multi-factor authentication, limited privileges, maintained components and controlled application credentials remain relevant. Browser-login MFA does not automatically add a second factor to every application-password integration; those credentials need separate management.
The historical comparison surveyed twelve addresses and obtained ten REST indexes. The counts describe reachable indexes, not twelve proven WordPress installations or anonymous write access. Comparison of REST route inventories across sites.
Questions and answers
Does blocking the users collection hide all author information?
No. Author archives, article bylines, feeds and oEmbed can expose public author details. Core oEmbed can include a display name and author URL for public embeddable posts. Availability and fields depend on filters and configuration. Removing one route does not establish that every other source is absent.
Is a different display name always harmless?
No. A public name can identify a person even when unrelated to the login. Publication requires a clear decision about which name and other author details should be public. Authentication should remain robust even when the account identifier is known.
Does a high route count mean an insecure site?
No. Complexity increases review work, but security depends on data exposure, permission checks and maintained code. Public read access and correctly denied writes can coexist on the same route.
Sources
- WordPress 4.7: REST content endpoints
- WordPress REST API: Discovery
- WordPress REST API: Routes, namespaces and permissions
- WordPress REST API: Custom content types
- WordPress REST API: Post fields
- WordPress REST API: User fields
- WordPress Core: User collection filtering
- WordPress Core: User names and slugs
- WordPress Core: Public oEmbed data
- WordPress REST API: Authentication and capabilities
- WordPress REST API: Disabling access and compatibility
- WordPress: Security hardening
- RFC 9110: HTTP response status semantics
Related articles
