What is the WordPress REST API?

The WordPress REST API is a built-in interface that lets external applications, JavaScript-based frontends, mobile apps, and third-party services communicate with your WordPress site using standard HTTP requests and JSON data. It was merged into WordPress core in version 4.7 (December 2016) and has since become the backbone of modern WordPress development, powering everything from the Gutenberg block editor to headless WordPress architectures.

Before the REST API existed, the only programmatic way to interact with WordPress from outside was through XML-RPC, an older and much more limited protocol. The REST API replaced that approach with something far more flexible, but it also introduced new security considerations that every WordPress site owner should understand.

Default Endpoints and What They Expose

The REST API lives at /wp-json/wp/v2/ on every WordPress installation. Out of the box, it exposes a wide range of endpoints:

• /wp-json/wp/v2/posts: returns all published posts with their full content, author IDs, categories, tags, and featured image references.
• /wp-json/wp/v2/pages: same as posts but for static pages.
• /wp-json/wp/v2/users: lists all users who have published at least one post. This is the most security-sensitive default endpoint.
• /wp-json/wp/v2/categories and /wp-json/wp/v2/tags: return taxonomy terms with descriptions and post counts.
• /wp-json/wp/v2/comments: lists public comments, including commenter names and sometimes email addresses if the site is misconfigured.
• /wp-json/wp/v2/media: lists uploaded media files with their URLs, dimensions, and metadata.
• /wp-json/wp/v2/search: provides a search endpoint that mirrors the site's built-in search.
• /wp-json/ (the root): returns a full index of all registered API namespaces and routes, effectively revealing every plugin that registers its own API endpoints.

Plugins frequently add their own namespaces. WooCommerce adds /wp-json/wc/v3/, Yoast SEO adds endpoints under its namespace, and contact form plugins may expose submission endpoints. The root API index reveals all of these, giving an attacker a clear picture of which plugins are installed.

The User Enumeration Risk

The /wp-json/wp/v2/users endpoint is the most discussed security concern with the REST API. By default, anyone can visit this endpoint and get a JSON response listing all users who have authored content. Each user entry includes their username (the slug field), display name, user ID, avatar URL, and a link to their author archive.

Why does this matter? Because usernames are half of the login equation. If an attacker knows that your admin account uses the username sarah_admin, they only need to guess (or brute-force) the password. Without the REST API, finding usernames required more effort, such as guessing author archive URLs like /?author=1. The REST API hands this information out freely in a structured, machine-readable format.

This is not a theoretical concern. Automated bots routinely scrape /wp-json/wp/v2/users on WordPress sites to build target lists for credential stuffing and brute-force attacks. If your site has a user named admin, that account will be the first one targeted.

Authentication Methods for the REST API

Unauthenticated requests to the REST API only return publicly available data (published posts, public user profiles, etc.). To create, update, or delete content through the API, you need authentication. WordPress supports several methods:

• Cookie Authentication: this is what the Gutenberg editor uses. When you are logged into WordPress, your browser sends session cookies with each API request. A nonce value prevents cross-site request forgery. This method only works within the browser context.
• Application Passwords: introduced in WordPress 5.6, this feature lets you generate unique passwords for each application that needs API access. Each application password is tied to a specific user account. You can revoke them individually without changing your main password. They are sent via HTTP Basic Auth and only work over HTTPS.
• JWT (JSON Web Tokens): not built into WordPress core, but available through plugins like "JWT Authentication for WP REST API." JWT is popular for headless WordPress setups where a frontend application needs to authenticate users and make API calls on their behalf.
• OAuth: also available through plugins. OAuth is the preferred method when third-party applications need to access your site's API on behalf of your users, because it avoids sharing passwords directly.

When You Actually Need the REST API

The REST API is not some optional feature you can casually turn off. It is deeply integrated into WordPress core and many plugins depend on it:

• Gutenberg Block Editor: the entire editing experience relies on the REST API. Every time you create, save, or preview a post in the block editor, it communicates with the REST API. Disabling it would force you back to the Classic Editor.
• Headless WordPress: if you use WordPress as a content management backend with a separate frontend built in React, Vue, Next.js, or Nuxt, the REST API (or its newer counterpart, WPGraphQL) is how the frontend retrieves content.
• Mobile Apps: the official WordPress mobile app communicates with your site through the REST API. Many custom apps for membership sites, learning platforms, or news outlets also use it.
• Plugin Functionality: many modern plugins rely on the REST API for their admin interfaces. Plugins that use React or Vue for their settings pages make API calls behind the scenes. WooCommerce, Jetpack, Yoast SEO, and dozens of others would break without it.
• Third-Party Integrations: Zapier, IFTTT, and similar automation tools can interact with your WordPress site through the REST API, enabling workflows like automatically creating posts from form submissions or syncing content between platforms.

Security Hardening Without Breaking Things

The correct approach is not to disable the REST API entirely, but to restrict the parts that expose sensitive information. Here are practical steps:

• Restrict the users endpoint: require authentication for /wp/v2/users. Several security plugins offer this with a single toggle. You can also add a code snippet to your theme's functions.php or a custom plugin that hooks into rest_authentication_errors to block unauthenticated access to specific endpoints.
• Remove the REST API link from HTML: WordPress outputs a <link rel="https://api.w.org/"> tag in the HTML head, advertising the API URL. Removing this tag does not disable the API, but it stops advertising its location to automated scanners.
• Disable XML-RPC alongside: if you are securing the REST API, also disable the older XML-RPC interface (/xmlrpc.php), which has its own set of brute-force and DDoS vulnerabilities.
• Use a firewall plugin: plugins like Wordfence, Sucuri, or iThemes Security can limit API access by IP address, block known malicious bots, and add rate limiting to prevent automated abuse.
• Remove unused plugin endpoints: if a plugin registers API routes you do not need, you can use the rest_endpoints filter to remove them. This reduces your attack surface and also prevents information leakage about which plugins you have installed.

What InspectWP Checks

InspectWP checks whether the REST API is publicly accessible by looking for the <link rel="https://api.w.org/"> tag in your site's HTML source. It also tests whether the /wp-json/wp/v2/users endpoint returns user data without authentication, which would indicate a user enumeration risk. If the API link tag is present, InspectWP reports the discovered REST API URL. If user data is exposed, it is flagged as a security concern with a recommendation to restrict that endpoint to authenticated requests only.