WordPress REST API Security: What to Expose and Restrict

Short answer: The WordPress REST API is switched on by default and lets anyone read public content, such as posts, pages and media, in a machine-friendly format. That is normal and mostly harmless, but it can also reveal user names, plugin routes and other details you may not want public. Do not turn the whole API off, because the editor and many plugins depend on it. Restrict what is sensitive and keep every write action behind authentication.

What the REST API is

The REST API is a set of web addresses that return WordPress data as structured text instead of a finished web page. Since version 4.7 it has been part of WordPress core. Your site answers requests at addresses that start with /wp-json/, and mobile apps, the block editor, page builders and many plugins use it to read and save content without reloading the page.

Because it is a standard feature, an attacker does not need to discover it. Anyone can open /wp-json/ in a browser and see the list of routes your site offers. That list is not a vulnerability in itself. It is more like a menu, and what matters is which dishes can be ordered without a login.

What is public by default

Out of the box, the API serves the content that your site already shows to visitors. Published posts, pages, categories, tags, comments and media files can be read without logging in. This is the same material that appears on your public pages, so exposing it in another format does not leak secrets.

Things that are not meant to be public, such as drafts, private posts and settings, require authentication. A request to change anything, for example to create a post or delete a comment, must carry valid credentials. WordPress supports cookie login for the editor and application passwords for outside tools. This split between public reading and protected writing is the core of the design, and it works well when plugins respect it.

The user list: the most common exposure

The route that draws the most attention is the list of users. On many sites, a request to /wp-json/wp/v2/users returns the public name, the user slug and sometimes the profile link of every account that has published a post. The user slug is often identical to the login name, which gives an attacker half of a login pair. Our article on WordPress user enumeration explains the other ways that names leak and why the leak matters.

Knowing a valid login name does not break into a site. It does make password guessing easier, so it pairs badly with weak passwords and no login protection. The practical answer is to block the users route for visitors who are not logged in, use a display name that differs from the login name, and add brute-force protection on the login page. Several security plugins and a few lines of code can limit the route to administrators.

Why you should not disable the whole API

Many guides suggest switching the REST API off completely. This advice is outdated. The block editor uses the API to load and save content, so disabling it can stop you from editing posts. Contact forms, e-commerce plugins, caching tools, the Site Health screen and many themes also depend on it. Turning it off often causes strange errors that are difficult to trace back to the cause.

A better approach is selective restriction. Allow public read access to the routes that serve your content, require login for everything else, and treat any custom route added by a plugin as something to review. If you really do not use the API on a small brochure site, an experienced developer can limit it to logged-in users. Test the editor and all forms afterwards, and keep a backup so that you can undo the change.

Plugin routes and custom endpoints

Plugins and themes can add their own routes under /wp-json/. This is where real vulnerabilities usually appear. A developer registers a route and forgets to check permissions, so that an action meant for administrators can be called by anyone. Historic WordPress security reports include several serious cases of this kind in popular plugins.

You cannot audit the code of every plugin, but you can reduce the risk:

Install only plugins you need and remove the rest.
Keep everything updated, because most fixes for route problems arrive as ordinary updates.
Avoid plugins that have not been updated for a long time, as described in our guide to abandoned WordPress plugins.
Open /wp-json/ once in a while and read the list of namespaces. A namespace for a plugin you removed years ago is a sign of leftover code.

Authentication and application passwords

Outside tools that write to your site need to prove who they are. WordPress offers application passwords, a separate password created for one purpose that can be revoked without changing your main password. They are convenient and, when used properly, safer than sharing a real login.

Create one for each tool, name it clearly, and delete it when the tool is no longer used. Give the connected user the lowest role that does the job, an idea we cover in website user roles and least privilege. Combine this with two-step login for the human accounts and strong passwords, and a leaked application password stays a limited problem instead of a full takeover.

How to check your own site

You can review the exposure in a few minutes without special tools. Open your-site.com/wp-json/ and scan the list of routes and namespaces. Then open your-site.com/wp-json/wp/v2/users in a private browser window, where you are not logged in, and see what comes back. If a list of names appears, decide whether to restrict it.

Look at the response of a protected route as well. A request to a write action without credentials should return an authorisation error and not a success. If you use a web application firewall, check that it does not block the API for your own editors. Our overview of the web application firewall explains what such a layer can and cannot do for a WordPress site.

Scraping, heavy requests and a hardening plan

Public routes can be requested by anyone, including automated tools. A scraper can read every post through the API in a few minutes, and a badly written bot can send thousands of requests an hour. On a small hosting plan this may slow the site for real visitors. The API is not more dangerous than your normal pages here, but it is easier to harvest because the data arrives already structured.

Caching helps, because repeated reads of the same content are served without extra work. A firewall or content delivery network can also limit the number of requests from one address. If you notice a sudden rise in load, read the server logs and look for requests to /wp-json/ from the same few addresses. Our guide to reading access logs to spot attacks shows what to look for.

If you want a simple order of work, follow these steps:

Update WordPress, themes and plugins, and delete the ones you do not use.
Check the users route while logged out and restrict it if it lists names.
Use a display name that is not the login name for every author.
Turn on two-step login for administrators and editors.
Review application passwords and delete those you no longer need.
Record the changes you made, so that a later update or a new developer does not undo them by accident.

None of these steps requires turning off the API, and together they close the most common doors. Repeat the quick check after major updates, because new plugins can change what your site exposes.

What Site AI Audit can tell you

Site AI Audit checks the security basics of your website from the outside: the SSL certificate and its expiry, the HTTP to HTTPS redirect, security headers and exposed software versions. It does not test individual REST API routes or list user names, so use the manual check above for that. It will, however, show you whether your site sends the security headers and hides version details that make an attacker’s job easier. You can run a free check of your website or see the plans.

The bottom line

The REST API is a normal and useful part of WordPress. Leave public content readable, keep every write action behind a login, limit the user list and review the routes that plugins add. Selective restriction protects your site without breaking the editor, and a few minutes of checking now and then catches most surprises.

SSS

Is the WordPress REST API a security risk?

Not by itself. It serves content that is already public and protects write actions with authentication. Risk appears when a plugin adds a route without proper permission checks or when it exposes user names.

Should I disable the REST API completely?

Usually no. The block editor, forms and many plugins need it. Restrict the sensitive routes and require login where it makes sense instead of turning everything off.

How do I hide user names in the API?

Block the users route for visitors who are not logged in, either with a security plugin or a small code snippet, and use a public display name that is different from the login name.

What are application passwords?

They are separate passwords for outside tools that connect to your site. You can create and revoke each one without touching your main password, which limits the damage if one leaks.

How can I see which routes my site offers?

Open the /wp-json/ address of your site in a browser. The response lists the namespaces and routes that are registered, including those added by plugins.