WordPress REST API Exposure Checklist: Audit Public Routes and Authentication

Last reviewed: April 14, 2026

WordPress operators often talk about the REST API as if it were either a feature they use intentionally or a thing they should disable. Production reality is more specific than that. The REST API is part of how modern WordPress works, and it is also a structured way for plugins, headless frontends, and external systems to interact with content and administration flows. The real operational question is not whether the REST API exists. The real question is whether the team understands what is public, what requires authentication, which custom routes have been added, and how external access is authenticated.

That distinction matters because the official REST API handbook is clear: content that is public on your site is generally publicly accessible via the REST API, while private content and restricted resources require authentication unless you explicitly make them public. A good audit therefore focuses on what is intentionally exposed, how clients discover it, and whether the authentication model for writes or privileged reads is appropriate for production.

Who this guide is for

This article is for WordPress administrators, agencies, platform teams, and developers operating either traditional or headless WordPress sites. It is especially relevant for sites with custom plugins, external integrations, mobile apps, dashboards, or separate frontends that depend on the API.

Key takeaways

• The WordPress REST API is not automatically a vulnerability; it is an application surface that should be inventoried and governed.
• Public content is generally public through the API as well, so route review should start with intent and data exposure, not with vague “turn it off” advice.
• Authentication method matters: internal dashboard or theme code should use cookie auth and nonces, while external applications should use safer production methods such as Application Passwords over HTTPS when appropriate.

WordPress REST API exposure checklist

1. Start by defining what your site intends to expose publicly. The REST API handbook states that public content is generally publicly accessible via the API, while private content and restricted resources are not unless authenticated or explicitly exposed. That means an audit should begin with a policy question: which post types, taxonomies, media, metadata, and custom endpoints are supposed to be public? If the team cannot answer that clearly, route review becomes guesswork.
2. Inspect the API discovery surface and index routes. WordPress documents discovery and the API index for a reason: clients can identify what resources exist and where they are located. Operators should fetch /wp-json/, review the namespaces and top-level routes, and treat that as the public inventory baseline. This is the fastest way to see which plugin or application features have added routes beyond the core content endpoints.
3. Pay special attention to custom or plugin-added endpoints. The REST API routes and endpoints handbook explains that endpoints are registered with callbacks, arguments, and permission callbacks. That is an implementation detail with operational consequences. When a plugin adds routes, the operator should know whether those routes are intentionally public, authenticated, or mis-scoped. A route can be perfectly valid code and still be a bad production exposure if no one remembers why it exists or who consumes it.
4. Use the right authentication model for the client type. The official authentication docs distinguish cookie authentication with nonces for requests inside WordPress from Application Passwords over HTTPS for external clients. That distinction is production-critical. Internal admin or theme code should not be treated like a remote integration, and remote integrations should not be using ad hoc developer shortcuts if a safer built-in authentication path exists. The same documentation explicitly notes that some basic-auth plugin approaches are for development and testing, not production.
5. Verify what an unauthenticated request can actually retrieve. An API audit is not finished because the route list looks familiar. Test unauthenticated requests to the routes your site depends on and confirm the responses match your public-content policy. Then test authenticated reads or writes only where they are supposed to exist. The point is to compare actual response behavior against intended access, not merely to inspect registered endpoints on paper.
6. Review how external applications are scoped and owned. If a headless frontend, automation script, or internal dashboard uses the REST API, record which routes it uses, which account or Application Password it authenticates as, and who owns that integration. The dangerous pattern is not the API itself. It is privileged access without clear ownership or route scope. If an integration exists but no one can explain its auth path or business purpose, that is a review finding.
7. Keep the audit tied to application change management. Route inventory should be revisited after plugin installs, custom feature releases, major theme changes, and headless frontend changes. The API surface is part of the live application contract. Treat it like code and infrastructure: review it when those systems change, not only after a scare.

Useful commands or validation steps

# Review the API index
curl -s https://example.com/wp-json/

# Inspect a known public collection
curl -s 'https://example.com/wp-json/wp/v2/posts?_fields=id,slug,link'

# Test authenticated access with an Application Password over HTTPS
curl --user 'USERNAME:APP_PASSWORD' 'https://example.com/wp-json/wp/v2/users?context=edit'

# Check a custom route or namespace manually
curl -s https://example.com/wp-json/your-namespace/v1/

These are intentionally simple because the first operational goal is visibility. Start with the index, confirm what is public without auth, and then test the authenticated paths that your integrations actually use. That gives you a practical inventory before you decide whether any route or integration needs to change.

What to verify before calling the API audit complete

• The team can explain which resources are meant to be public.
• Custom namespaces and plugin-added routes have an owner and a purpose.
• Unauthenticated responses match the intended public-content policy.
• External integrations use an appropriate production authentication model.
• Privileged API access is documented and revocable.

Common mistakes

• Treating the REST API as either harmless by default or dangerous by default. It needs an actual route and auth review.
• Ignoring custom plugin namespaces because core routes look normal.
• Using development-style auth patterns in production for remote integrations.
• Forgetting that public site content is often publicly accessible through the API too.
• Not documenting who owns external clients and their credentials.

What to document or review next

• The approved public API surface for the site.
• The list of custom namespaces, integrations, and their owners.
• The authentication method used by each external client or headless frontend.

Related reading

If your integrations still authenticate with broader privileges than they need, pair this with WordPress Application Password Security Checklist: Create, Scope, Rotate. If the site is a backend-only deployment, follow it with Headless WordPress Security Checklist: 5 Controls to Enable Before Launch.

References and further reading

• REST API Handbook
• REST API Handbook: Using the REST API
• REST API Handbook: Authentication
• REST API Handbook: Discovery
• REST API Handbook: Routes and Endpoints