Restrict the WordPress REST API Without Automatically Breaking Everything
The WordPress REST API is an important part of modern WordPress. It allows applications to interact with site data through structured HTTP endpoints and is used by WordPress itself as well as many plugins, themes, mobile applications, and external integrations.
That means "disable the REST API" is not as simple as turning off an unused feature.
Completely blocking REST can affect the Block Editor, Site Editor, media workflows, applications, and plugin functionality. At the same time, some websites have no reason to expose WordPress's core REST data to anonymous visitors.
WP PowerSuite addresses this with two distinct modes instead of treating every website the same. For most security-hardening scenarios, Disable Public Access Only is the appropriate choice. It restricts anonymous access to WordPress core REST endpoints while keeping authenticated WordPress functionality available.
When a site has a genuine requirement to eliminate REST access altogether, the stronger Disable Completely mode remains available.
Block Anonymous Core REST Access While Keeping WordPress Usable
The default Disable Public Access Only mode is designed to provide a practical balance between REST API hardening and compatibility.
Anonymous visitors are prevented from accessing WordPress core REST namespaces such as wp/v2, Site Health, Block Editor, abilities, and oEmbed endpoints. Requests to the REST index and future routes following WordPress's core namespace conventions are covered as well.
Logged-in users continue to have full REST access.
This distinction matters because modern WordPress administration relies heavily on REST. An editor working inside the Block Editor may need REST requests to load, save, and interact with content. Preventing those requests for authenticated users would create unnecessary compatibility problems when the actual goal is simply to prevent anonymous visitors from querying core endpoints.
When a guest requests a protected core route, WP PowerSuite returns an authentication-required REST response rather than exposing the requested data.
Keep WooCommerce and Plugin REST APIs Separate
A common problem with aggressive REST-blocking snippets is that they treat every endpoint as if it belongs to WordPress core.
Many WordPress plugins depend on their own REST namespaces. WooCommerce, form builders, membership systems, payment integrations, frontend applications, and other plugins may expose endpoints required for normal site functionality.
In Disable Public Access Only mode, WP PowerSuite deliberately targets WordPress core namespaces rather than blindly shutting down the entire REST server.
Third-party namespaces remain available unless another security rule or the plugin itself restricts them.
This makes public-only mode significantly more practical for real WordPress websites where the core API may not need to be anonymous but plugin functionality still depends on REST.
It is still important to test important frontend functionality after changing REST access, particularly on sites with custom integrations.
Completely Disable the WordPress REST API When Necessary
Some environments have stricter requirements and may genuinely need REST disabled for everyone.
Disable Completely blocks REST access for anonymous visitors and authenticated users alike. Requests receive a 403 response unless a developer has explicitly allowed the route through the available filter.
This mode is intentionally accompanied by a confirmation because the compatibility impact can be substantial.
The WordPress Block Editor, Site Editor, media functionality, mobile applications, REST-based tools, and many plugins can depend on the REST API. Completely disabling it can therefore break functionality even for administrators.
For that reason, complete disable should be used when you understand the dependencies of the website and have a specific reason to block REST entirely. It should not be treated as a universally "more secure" setting that every WordPress installation should enable.
Reduce Public WordPress REST Discovery
Restricting access to REST routes addresses the requests themselves, but WordPress can also advertise its REST interface in several places.
With REST discovery removal enabled, WP PowerSuite removes the standard REST link from the frontend HTML and the related HTTP Link header. It also removes relevant oEmbed discovery links and the REST-related entry exposed through WordPress's RSD output.
These changes reduce passive discovery of WordPress REST endpoints while leaving the actual access policy controlled by the selected REST mode.
Discovery removal should be understood as cleanup and exposure reduction rather than the primary security control. A REST endpoint does not become secure merely because its discovery link is hidden. The important protection is the access restriction applied to the REST request itself.
Reduce Public WordPress User Enumeration
WordPress core REST endpoints can expose information about users in configurations where anonymous access is available.
Because Disable REST API's public mode already restricts WordPress core routes, it also covers the core user endpoints that related WP PowerSuite security modules would otherwise need to guard separately.
For example, Disable Author Archives can remove public author archives entirely, while Hide Author URLs can keep those archives but replace normal author slugs with randomized identifiers. Both modules include their own REST-related safeguards when used independently.
When Disable REST API is enabled, those modules recognize that core REST access is already being handled and avoid applying redundant user-endpoint restrictions.
This allows the modules to work together as separate layers: one controls the REST API, while the others control how WordPress exposes public author information.
Choose the Right REST Mode for Your Website
For most conventional WordPress websites looking to reduce unnecessary public API exposure, Disable Public Access Only is the sensible starting point.
It blocks anonymous access to core WordPress REST routes while keeping authenticated administration available and leaving third-party namespaces untouched by default.
Disable Completely is considerably more aggressive. It is better suited to controlled environments where you know the website does not depend on REST or where an explicit allow-list has been built for the routes that must remain available.
Whichever mode you choose, test the website afterward. Check content editing, media, forms, WooCommerce functionality, account areas, integrations, and any frontend features that may communicate through REST.
Security controls are most useful when they reduce unnecessary exposure without breaking functionality the website actually needs.
