What the Public WordPress API Reveals: Checking REST Routes and Data Access

A WordPress REST index describes publicly visible API routes. A route is an addressable path; an endpoint combines that path with an HTTP method and a handler. An index entry therefore does not imply anonymous access to every associated record or write operation.

Finding the index

The entry point is often /wp-json/. A better starting point is the discovery link published by WordPress with the relation https://api.w.org/, for example in an HTTP header or HTML. Subdirectories, changed prefixes and intermediate systems can affect the actual API URL.

WordPress also supports ?rest_route=/, including configurations with pretty permalinks. Blocking one URL path therefore does not prove complete access restriction. Conversely, a 404 at a guessed path proves neither that the API is disabled nor that the site runs WordPress.

A route count is not a plugin inventory

A namespace such as vendor/v1 groups routes. The version number normally denotes an API version, not an installed plugin release. Extensions can register several namespaces, add routes to existing namespaces or operate without REST routes. Themes and custom code can also add routes. Publicly visible index data can additionally be filtered.

The count therefore describes entries in the particular index response. It is neither a complete list of installed plugins nor a measure of vulnerabilities. Similar counts do not prove a shared platform either. A complete extension inventory requires administrative inventory data.

A declared method such as POST or DELETE documents an interface. An anonymous GET sample does not test write permissions. The relevant evidence is the actual permission check and the data returned under the specific request conditions.

Status and content belong together

• 200: The HTTP request succeeded. Content type, complete parseable JSON and the expected structure are still needed to identify the actual REST response. An HTML blocking page with status 200 is not a user list.
• 401 or 403: The specific request was rejected. A WordPress error, a firewall and an upstream service are different causes. The status does not establish correct permissions throughout the API.
• 404: No matching resource was served at that address. An incorrect path, a removed route or upstream rules remain possible explanations.
• Failure or truncated JSON: The count has not been reliably determined. A displayed zero must not be interpreted as proof of zero existing routes.

Public authors are not all user accounts

The default /wp/v2/users route can return public author data without authentication. Without the list_users capability, core restricts the normal collection to accounts with published posts in REST-visible post types. Filters and extensions can change that behaviour. Collections are also paginated, meaning the results are split across several responses. One response is not automatically the complete set.

The public slug field corresponds to the URL-friendly user_nicename, which can differ from the login name. The separate username field belongs to the protected editing context in the default schema; passwords are never returned. Public author names are therefore not an exposed password file and do not by themselves establish a vulnerability.

Public identifiers can nevertheless support unwanted contact or targeted login attempts. Assessment depends on the actual data returned and the intended level of publicity. Access protection still requires effective authentication and appropriate permissions. Hiding a single collection does not replace those controls.

Precise descriptions of permissions

WordPress checks capabilities rather than relying solely on role names. For example, the default settings route checks manage_options, while the plugin collection checks activate_plugins. Theme requirements also depend on the request. A blanket claim that all these routes require administrator privileges is therefore imprecise.

With cookie authentication, the REST nonce is an additional check value sent with the request. It helps protect against certain requests triggered by another website through a logged-in browser. A nonce replaces neither authentication nor permission checking. Other supported methods, such as application passwords over HTTPS, do not use the same cookie/nonce combination. Not every valid REST request requires a nonce.

Limits of the route inventory tool

The linked inventory tries /wp-json/ and, under certain failure conditions, ?rest_route=/. Ten fixed GET samples follow. This is neither complete API discovery nor testing of every method.

The current evaluation classifies samples solely by HTTP status. A local test using a synthetic HTML blocking page with status 200 therefore produces an open label. An empty JSON list receives the same label. In this implementation, that label does not demonstrate disclosure of user accounts.

The fetch limit is 8 MiB. A truncated index produces a warning, but the numerical route count in the current output remains zero. Only the first 4096 content bytes of each sample reach the evaluation, so a larger valid JSON response can become unparseable. There is no complete user count or pagination. Namespace grouping also uses only the first two path segments, which can incorrectly combine longer namespaces.

Six local test cases check these evaluation limits using synthetic responses. The results do not constitute a new ranking of third-party installations or a security assessment of those sites.

A related article discusses public data in the WordPress REST API.