WordPress REST API Tester

1. The WordPress REST API Specification

The WordPress REST API has shipped with WordPress core since version 4.7 (2016) and provides JSON endpoints for posts, pages, taxonomies, media, and users — documented in full at the official WordPress REST API Handbook. Some endpoints (like published post content) are intentionally public by design, since the API is meant to let JavaScript apps and external tools read site content the same way a visitor's browser would. Other endpoints (like user data) expose more than a typical visitor needs to see, which is where the security consideration in this tool comes in.

2. Mitigating User Enumeration Vulnerabilities

If this test reports the users endpoint as publicly exposed, the fix is to restrict unauthenticated access to it — via a `rest_endpoints` filter, a maintained security plugin, or your host's WAF rules — while leaving the endpoints your site actually needs public (post content, categories) untouched. It's worth checking after the fix that legitimate uses of the API (if you have a headless front end, a mobile app, or third-party integrations reading post data) still work correctly, since an overly broad REST API lockdown can break functionality you didn't intend to affect.

3. Auditing Login Endpoint Hardening

User enumeration is only useful to an attacker if there's somewhere to use the discovered usernames — and /wp-login.php is exactly that target. Once you've checked REST API exposure here, audit the login endpoint itself (rate limiting, XML-RPC exposure, security headers) with the WordPress Login Security Checker for the complete picture.

4. The REST API's Role in Static Edge Rendering

Nimbica reads WordPress content through the REST API at build time to generate static HTML — this is a legitimate, intended use of the same public post/page endpoints this tool checks, distinct from the sensitive user-data endpoint that needs restricting. Locking down `/wp-json/wp/v2/users` doesn't interfere with this kind of content-reading integration, since post and page data typically remain public by design.

5. How to Use This Test

1. Run the scan against your site's URL and note both results: REST API availability and user enumeration exposure.
2. If the users endpoint shows as exposed, apply a fix (filter, plugin, or WAF rule) and re-run the scan to confirm it's now returning a non-200 status or empty data to unauthenticated requests.
3. If REST API is reported unavailable but you expected it to work (e.g. for a headless integration), check whether a security plugin has disabled more than intended.
4. Use the response time figure as a rough indicator of backend health — a very slow REST response often correlates with the same server-side bottlenecks that slow down normal page loads.

6. Common Mistakes

• Disabling the entire REST API instead of just the users endpoint. A blanket lockdown can silently break plugins, mobile apps, or headless integrations that legitimately depend on other REST endpoints — restrict only what needs restricting.
• Assuming this one fix eliminates username enumeration entirely. WordPress has other enumeration vectors (author archive URLs like `?author=1`, XML-RPC, login error messages) that need separate attention — see the Login Security Checker.
• Treating a fast REST response as proof of good overall site security. Response time measures performance, not safety — a fast site can still have the users endpoint wide open.

7. Who Should Use This Tool

Site owners and developers doing a basic WordPress security self-check, agencies performing a hardening audit for a client, and anyone building or debugging a headless/REST-based integration who wants to confirm which endpoints are actually reachable from outside.

8. Limitations

This test checks exactly two endpoints (the API root and the users list) via passive, unauthenticated GET requests — it is not a comprehensive REST API security audit and does not test authentication, authorization on write operations, custom plugin-registered endpoints, or rate limiting. A clean result here means these two specific checks passed, not that the site's REST API surface is fully secure.