Skip to main content
FyrePress Logo

REST API Restrictor

Lock down your WordPress data and prevent anonymous endpoint scraping.

Functions.php Snippet

Information Leakage: The Invisible Risk

By default, the WordPress REST API is open to everyone. While this enables modern features, it also inadvertently exposes your site's architecture to bad actors. Attackers use the /wp-json/wp/v2/users endpoint to easily scrape every username on your site-half the battle won for a brute-force attack.

Furthermore, other endpoints can leak plugin lists, taxonomy structures, and published content in a machine-readable format that is trivial to scrape for vulnerabilities. Restricting REST API access ensures that only authenticated users (logged-in administrators or authors) can access this sensitive JSON data.

Gutenberg & Frontend Impact

The modern WordPress editor (Gutenberg) relies heavily on the REST API. Total restriction can cause "Update failed" errors in the dashboard. Our snippet is designed to only block unauthenticated public requests, keeping your admin dashboard fully functional while locking the front door to bots.

Deployment: Securing the API Safely

Implementing this restriction via PHP is preferred over `.htaccess` because it allows WordPress to gracefully handle the request and return proper JSON error messages. Follow these steps for a clean install:

1. Access functions.php

Open your active child theme's functions.php file. Never edit the parent theme directly, as your security patches will be wiped during the next theme update.

2. Integration

Paste the generated snippet at the very end of your file. The snippet uses the rest_authentication_errors hook, which is the official WordPress way to intercept API requests before they are processed.

3. Verification Test

Open an "Incognito" or "Private" browser window and visit yourdomain.com/wp-json/wp/v2/users. You should see a JSON response stating that you are not authorized to access that endpoint. Then, log in as an admin and visit the same URL-you should see the user list as normal.

Operational Use Cases and Risk Controls

This REST API Restrictor page is intended to apply controlled access rules to WordPress REST endpoints. Treat generated output as an implementation draft that still needs environment-specific validation, peer review, and rollback planning.

In production, reliability comes from process: define scope, generate output, test realistic scenarios, deploy with change tracking, and verify outcomes with logs/metrics. Teams that follow this sequence reduce repeat incidents and accelerate approvals.

High-Value Use Cases

  • Lock down sensitive endpoints to authenticated users only.
  • Protect high-risk routes from anonymous scraping.
  • Implement staged API access policies during incident response.
  • Pair endpoint restrictions with token-based auth strategies.
  • Document API exposure decisions for audits.

Common Pitfalls to Avoid

  • Over-restriction can break mobile apps or headless frontends.
  • Role checks without capability mapping can leak data.
  • Blocking core endpoints may disrupt plugin features.
  • No integration tests can hide regressions until production.
  • Access policy drift accumulates after plugin updates.

Before production rollout, run one valid case, one invalid case, and one edge case, then record results in your runbook. This lightweight checklist is often enough to catch hidden assumptions before they become outages.

Stop reconnaissance in its tracks.

Restrict anonymous REST API requests and keep your WordPress architecture private.

What is the REST API Restrictor?

WordPress exposes a powerful REST API at /wp-json/ that unauthenticated visitors can query by default. This means anyone can retrieve a list of your user accounts, post slugs, plugin data, and other architectural details without ever logging in. For most sites, that level of openness is an unnecessary attack surface.

The REST API Restrictor generates a PHP snippet that limits API access to authenticated users only, or blocks public endpoints entirely. It lets you choose the right level of restriction without hand-writing complex authentication checks against every REST request.

Restricting the REST API is especially valuable on membership sites, internal tools, and any WordPress installation where you do not want the site's data structure to be publicly discoverable. It is one of the first hardening steps recommended for sites that handle private or sensitive content.

The snippet hooks into the rest_authentication_errors filter, which is the official WordPress mechanism for blocking unauthenticated REST requests. This keeps your code compatible with core updates and avoids fragile workarounds like disabling the REST API through rewrites.

Because the Block Editor itself uses the REST API for every save, preview, and media operation, the snippet preserves full access for logged-in users. You get a locked front door without disrupting your own editing workflow.

How to use the REST API Restrictor

Follow these steps to generate production-ready output.

1

Choose Restriction Mode

Select whether to require authentication for all REST requests or allow specific namespaces through for third-party tools.

2

Configure Exemptions

Whitelist any routes that must remain public, such as contact form webhooks or payment gateway callbacks.

3

Copy & Deploy

Paste the snippet into your theme's functions.php or a site-specific plugin, then verify with a logged-out browser test.

Common Edge Cases & Critical Considerations

These are the most common issues teams run into when using this tool.

  • Plugin compatibility: WooCommerce, Jetpack, and some form builders rely on unauthenticated REST endpoints for webhooks and sync. Test thoroughly on a staging site before enabling restrictions in production.
  • Block Editor dependency: Gutenberg requires REST API access for every logged-in session. The snippet must preserve authenticated access or your entire post-editing experience will break immediately.
  • Headless & mobile apps: Decoupled front-ends and mobile applications must authenticate every REST request with Application Passwords or OAuth before the restriction is enabled, or they will lose access entirely.
  • JWT authentication plugins: Token-based auth plugins still need the REST API to be reachable for token exchange. A blanket block will prevent the auth flow from completing before a user can even log in.
  • Not a complete security solution: Restricting the REST API reduces your public exposure but does not replace strong passwords, two-factor authentication, updated plugins, and a properly configured firewall.

Frequently Asked Questions

Will restricting the REST API break the Gutenberg block editor?
No, as long as the restriction only applies to unauthenticated requests. The generated snippet checks is_user_logged_in() and returns a WP_Error only for anonymous callers. Editors and administrators retain full REST access during their logged-in sessions.
Can I whitelist specific REST API endpoints while blocking others?
Yes. Inside the rest_authentication_errors callback, you can inspect the current route and return null (pass through) for specific namespaces or paths. The generator includes an exemption array for this purpose so you can whitelist individual plugin routes.
Does restricting the REST API affect logged-in users?
No. The restriction targets anonymous visitors only. Any user with a valid WordPress session — subscriber through administrator — will continue to receive normal REST API responses for the routes their capabilities permit.
Is blocking the REST API enough to fully secure my WordPress site?
It is one important layer in a defense-in-depth strategy, not a complete solution. Pair it with strong admin passwords, two-factor authentication, updated plugins, HTTP security headers, and a web application firewall for meaningful protection.

Stop Guessing. Start Restricting.

Restrict anonymous REST API requests and keep your WordPress architecture private.