Is Your WordPress REST API Really Safe? Why Old Features Are Becoming New Risks

The WordPress REST API, especially the ability to retrieve user information via /wp-json/wp/v2/users, has long been known as a standard feature. As a result, many sites continue to operate under the assumption that “this is not a vulnerability” or “it’s just a specification, so it’s fine,” without implementing any specific countermeasures.

However, recently, this “long-standing feature” has increasingly become a situation where it is once again drawing attention as a security risk.

Why is this becoming an issue again now?

The main reason is changes in the environment. In particular, the following three factors are having a major impact.

• Automation and sophistication of attacks
• Increased use of REST APIs
• Greater exposure of data due to plugin integrations

Recently, bot-based scanning has become widespread, and automated access that systematically explores paths under /wp-json/ is increasing. This is not merely for information gathering, but is increasingly used as an entry point for attack chains such as user enumeration → login attempts → unauthorized access.

WordPress is being used as an “API server”

Another major change is the rise of Headless CMS architectures. Today, it is becoming common to separate the frontend and backend, using WordPress purely as an API.

• Frontend: Next.js / React
• Backend: WordPress (REST API)

In other words, WordPress is increasingly being used not as a “website,” but as an “API server”. As a result of this shift, public APIs themselves have become direct attack surfaces.

When a “feature” becomes a “risk”

The REST API itself is a feature, but depending on how it is used, it can become a risk. For example, retrieving user lists can lead to login ID identification, public APIs can be used for reconnaissance, and excessive exposure of custom data can lead to data leaks.

Individually, these may not seem problematic, but when combined, they can lead to real-world impact—which is the current situation.

Unintended data exposure through plugin integration

One increasingly common issue is data expansion through plugins. Custom fields added via tools like ACF or user meta information may be exposed directly through the REST API.

As a result, data that was never intended to be public may become externally accessible.

A common misconception: “It should be safe to expose this”

In many real-world cases, people assume things like “it’s only used by the frontend” or “we’re not exposing sensitive data.” However, in reality, attackers combine fragmented pieces of information.

Even something as simple as a username can significantly increase the success rate of login attacks.

Summary so far

To summarize, the REST API has always been part of WordPress, but the environment in which it is used has changed. As a result, the meaning of its risk has evolved.

In other words, the issue is not “a new vulnerability,” but “a change in how it is used”.

From here, we will move into more technical details and look at what kinds of configurations and implementations actually introduce risk.

What is the issue from a security perspective?

This issue can also be understood from an OWASP perspective, particularly in relation to “data exposure,” “security misconfiguration,” and “authentication failures.”

Among these, the most common issue is overexposure of public APIs due to misconfiguration.

Common implementation mistake: permission_callback

When implementing REST APIs in WordPress, one of the most critical elements is permission_callback. Misconfiguring this can unintentionally expose your API to the public.

register_rest_route('myapi/v1', '/users', [
  'methods' => 'GET',
  'callback' => 'get_users',
  'permission_callback' => '__return_true'
]);

This configuration means the API is accessible to anyone. In most cases, proper authentication checks should be implemented.

'permission_callback' => function () {
  return is_user_logged_in();
}

Real implementation example using REST API (from my Udemy course)

The concepts explained so far are not theoretical—they directly apply to real-world development. In particular, when building features using the REST API, design mistakes can directly lead to vulnerabilities.

For example, in my WordPress Plugin Development Course on Udemy, I demonstrate how to build a “real-time article search” feature using the REST API.

This feature uses JavaScript to call the WordPress API and display search results instantly, representing a Headless-style implementation pattern.

Within the course, I also conduct experiments to show what happens when the permission_callback configuration is changed.

• When permission_callback is set to __return_true
• When authentication checks are applied
• How much data can actually be retrieved

By observing these differences in practice, it becomes clear that a single configuration change can drastically alter the nature of a public API.

Additionally, since this is a search feature that handles user input, input handling and response design are directly tied to security.

In this way, while REST APIs are powerful, they must be designed with the understanding that implementation equals a publicly exposed interface.

If you are interested, try searching for terms like “WordPress REST API plugin development” or experiment hands-on to deepen your understanding.

Minimize output data

Another important aspect is response design. Returning entire objects as-is can lead to unintended exposure of unnecessary data.

Instead, it is important to explicitly return only the required fields.

return [
  'id' => $user->ID,
  'name' => $user->display_name
];

Key points to reassess in practice

In real-world environments, you should check the following points.

• Do you have a clear understanding of which REST APIs are publicly exposed?
• Is permission_callback properly configured?
• Are you exposing any unnecessary data?

Reviewing these alone can significantly reduce your risk. For more details, try searching for “WordPress REST API security” or “permission_callback.”

Conclusion: The issue is not “newness,” but “usage”

The key takeaway is that the specification hasn’t changed, but the environment has.

Today, WordPress is increasingly treated not as a “website,” but as an “API server”. Therefore, features that were once considered safe now need to be re-evaluated.

Take a moment to review your own REST API endpoints and ask yourself: “Is it truly safe to expose this?”