{"id":13605,"date":"2026-10-20T07:35:00","date_gmt":"2026-10-20T05:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13605"},"modified":"2026-09-25T09:45:54","modified_gmt":"2026-09-25T07:45:54","slug":"203-routes-what-the-wordpress-rest-api-hands-out-without-a-login","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/wordpress-plugins-tricks\/tutorials-en-wordpress-plugins-tricks\/203-routes-what-the-wordpress-rest-api-hands-out-without-a-login\/","title":{"rendered":"203 Routes: What the WordPress REST API Hands Out Without a Login"},"content":{"rendered":"

A WordPress site is two things at once. One is the pages a browser shows. The other is an interface that answers in plain data, has been switched on since the first minute, and is rarely looked at by whoever runs the site.<\/p>\n

It lives at \/wp-json\/<\/code>, and its first answer is a list of everything it can do.<\/p>\n

\n\"203
203 routes across nine namespaces, counted from the interface’s own index.<\/figcaption><\/figure>\n

What the interface is for<\/h2>\n

The REST API exists so that something other than a browser can work with a site: the block editor in the admin area, a mobile app, another site pulling in articles, a script that publishes on a schedule.<\/p>\n

It is part of WordPress itself rather than a plugin, and it has answered by default since 2016. Nothing has to be switched on for it to work.<\/p>\n

The consequence worth holding on to: whatever is published on the site is published here as well, in a form built for machines. Not a copy and not a summary – the same content, far easier to collect.<\/p>\n

203 routes on an ordinary site<\/h2>\n

The index at \/wp-json\/<\/code> answered with 203 routes across nine namespaces on the site measured here.<\/p>\n

110 of them belong to wp\/v2<\/code>, the core: posts, pages, media, comments, categories, tags, block types and the rest of the standard furniture.<\/p>\n

59 belong to a single plugin. That is more than a quarter of the whole interface contributed by one piece of software, and it is not unusual – a large plugin tends to register a route for every screen it owns.<\/p>\n

The remaining 34 are spread across seven namespaces, most of them holding between three and eight routes.<\/p>\n

The namespace list is a plugin list<\/h2>\n

The index does not only count routes. It names the namespaces, and a namespace is chosen by whoever wrote the plugin.<\/p>\n

So the answer to one unauthenticated request contains, in plain text, which plugins are installed: the SEO plugin, the multilingual plugin, the code-block plugin, and any custom code the site registers for itself.<\/p>\n

That is not a leak in the sense of something being broken. It is how the interface has to work, because a client needs to know what is available. It does mean, though, that the question “which plugins does this site run” has a one-request answer – and that answer is routinely used to look up which versions have known problems.<\/p>\n

\n\"A
\n<\/figure>\n

What answers without a login<\/h2>\n

Reading is largely open, which follows from the content being public anyway.<\/p>\n

Posts, pages, comments, categories, tags, post types, media and the routes added by the SEO and multilingual plugins all answered 200 with real content.<\/p>\n

One detail deserves a pause. A request for a single post returned 23,455 bytes: the complete rendered article, not an excerpt. Everything published is available at one request per post, cleanly separated into fields, without any of the surrounding markup a page would carry.<\/p>\n

What asks for a login, and the better refusal<\/h2>\n

Everything describing the installation rather than the content required authentication: the settings, the plugin list, the theme list, the block types, the site health checks. All of them answered 401.<\/p>\n

One route answered differently, and it is the one worth copying. wp\/v2\/users<\/code> returned 404.<\/p>\n

The difference is not cosmetic. A 401 or 403 confirms that the route exists and is being guarded, which tells a collector that the thing behind it is real and worth another attempt. A 404 says nothing at all. The route had been removed rather than protected, and from outside that is indistinguishable from a WordPress that never offered it.<\/p>\n

Author names are the usual reason for closing it. They are half of a login, and a public list of them is a public list of valid user names.<\/p>\n

What is worth checking<\/h2>\n

Three questions answer themselves in one request each.<\/p>\n

What does \/wp-json\/<\/code> list? Which namespaces appear, and does any of them belong to something no longer in use? A deactivated plugin registers nothing; an active but forgotten one registers everything it has.<\/p>\n

What does \/wp-json\/wp\/v2\/users<\/code> answer? A 200 hands out author names. A 401 confirms they exist. A 404 says nothing.<\/p>\n

And what comes back for a single post? If the answer is the whole article, that is the interface working exactly as designed – but it is worth knowing that this is a shape the content is available in, and not only as a page.<\/p>\n

The same two questions, how many routes \/wp-json\/<\/code> lists and what wp\/v2\/users<\/code> answers, were also put to twelve installations; the results, from 203 to 1,107 routes, are in 1,107 Routes Without a Login: What Ten WordPress Installations Hand Out at \/wp-json\/<\/a>.<\/p>\n

\n

Questions and answers<\/h2>\n

Is removing wp\/v2\/users enough to stop user names from getting out?<\/h3>\n

No, the route is merely the most convenient list. By default two other places give away the same thing:<\/p>\n