# Require sign-in for a WordPress REST API route, after a week

Close one public REST API route to signed-out visitors, but only after a week of watching who uses it, with Undo if a form or app stops working.

By M Asif Rahman, Nov 7, 2026.

You can require sign-in for one WordPress REST API route without switching the REST API off, and **BetterShield** makes you watch the route for a week before it lets you close it. The week shows who really uses the route, and **Undo** puts the old access back if a form, an app or a headless front end turns out to need it.

Our guide to [stopping user enumeration in WordPress](/blog/wordpress-user-enumeration/) closes one well-known REST route, the user list. This post is for any other public route a finding points at, and for deciding whether closing it is safe on your site.

## Quick summary

- A finding about a public REST route can offer a guided fix: **Require Sign-in** starts a week of observation for the route you choose.
- It is a targeted restriction on one route, not a switch that disables the whole REST API.
- After the week, **Close to Visitors** makes that route refuse callers who are not signed in.
- A signed-out app, public form or headless front end can lose access, so **Undo** restores the previous access.
- Seeing no matches in the week is not proof that a monthly task never uses the route.

## What a REST API route is, and why some are open

WordPress exposes its data and many plugin features through the REST API, a set of addresses that return structured data. The [WordPress REST API handbook](https://developer.wordpress.org/rest-api/) describes how routes and endpoints are registered, and it is clear that each one decides for itself who may call it. Some routes need a signed-in user. Others are public on purpose, because a contact form, a block, a map or a mobile app has to reach them without signing in.

That is the catch. A public route is sometimes a decision and sometimes an oversight. A plugin may expose data to everyone that only the site owner ever needed to see. From the outside you cannot tell the two apart by looking at the address.

BetterShield’s [security audit](/blog/wordpress-security-audit/) raises a finding when it sees a public route like that. Open the row’s **Explain** panel and the [evidence behind the finding](/docs/finding-details/) shows what was checked. What the audit cannot know is whether something on your site depends on that route being open. That is why the fix watches first.

## Why watch before closing

Closing a route that something relies on breaks it quietly. A newsletter form stops saving, a map stops loading, a mobile app shows an empty screen. Nobody reports it for days.

So BetterShield does not close a route on a guess. **Require Sign-in** starts observation for the route you choose, and the fix will not offer **Close to Visitors** until a full week has passed. The week is long on purpose: it should include scheduled jobs and infrequent integrations, the callers that do not show up on a quiet Tuesday.

## Set it up

1. Open **BetterShield › Findings** and find the finding about a public REST route.
2. Select **Explain** and read the evidence, then check the route against the plugins and services you know your site uses.
3. Select **Require Sign-in** for the route you want to restrict. BetterShield starts watching it.
4. Over the week, read the observed use: how many requests came from visitors who were not signed in, and where they came from. Test your forms, apps and any external front end that calls the route.
5. After the week, select **Close to Visitors** only if that route should not answer signed-out callers.

The step-by-step version is in the [REST route access guide](/docs/observe-rest-route/). If you would rather not close the route yet, **Stop Watching** ends the observation and leaves the route as it was.

## What to look for during the week

The watching week is the part of this fix that is easy to rush, so decide up front what would make you stop.

- **A caller you recognize.** A request from your own site, from a front end you built or from a service you pay for is a reason to leave the route public.
- **A caller you do not recognize.** Ask the person who owns the integration before you close anything. A route you did not choose to expose is the one most worth closing, but only once you know nobody needs it.
- **No requests at all.** That is encouraging, but it is not proof. A monthly report, a yearly renewal or a seasonal campaign may not have run yet.
- **Requests that stop on a schedule.** If the count rises every Monday morning, something runs on a timer. Find out what.

Keep routes public when their purpose requires public use. A route that a public form posts to is meant to answer signed-out visitors, and closing it defeats the form.

## What closing does, and what it does not

After **Close to Visitors**, the chosen route refuses callers who are not signed in. Other routes keep behaving as before. You are not turning the REST API off. You are closing one door.

It also does not make the data inside the route safe or private by itself. A signed-in account can still read it, which is why strong sign-in matters as much as the restriction. Our [WordPress hardening guide](/blog/wordpress-hardening/) shows where this fits among the other protections.

## What it can break and how to undo

A signed-out app, public form or headless front end can lose access when you close a route. The symptoms are usually plain: a form that no longer saves, a page that loads without its data, an app that reports it cannot connect.

To go back, use the fix’s **Undo**. It restores the previous access, and after that you should test the workflow again. If the route is still being watched, **Stop Watching** ends the observation without closing anything. Once the route is closed, **Open Again** makes it readable by anyone again and clears what was seen on it.

Every change is also recorded, so you can see when a route was closed. The [WordPress activity log](/blog/wordpress-activity-log/) holds that entry alongside your other site changes.

## Check it is working

1. Request the route while signed out, for example in a private browser window. It should refuse you after you close it.
2. Request the same route while signed in with the account that should have access. It should still answer.
3. Load the pages and run the forms that use your plugins. Confirm other routes still behave as before.
4. Open the activity log and read the entry for the change.

If anything fails, use **Undo** first and investigate second. A route that is public again is a known state. A broken checkout is not.

## Recommended settings

We recommend starting with the route the finding names and no others. Let the full week run, including a weekend and, if you can, the first of the month. Ask the owner of any integration you do not recognize before you close its route. Close it only when you can say who the route was for and that they are covered.

If you manage several sites, do this on a staging copy first when you can, and then repeat the week on the live site.

## Frequently asked questions

### Does this turn off the WordPress REST API?

No. It restricts one route you choose. The other routes keep working as before.

### Why does BetterShield make me wait a week?

Because a route that looks unused on a quiet day may be used by a weekly or monthly task. The week of observation lets those callers show up before anything is closed.

### What if I close a route and something breaks?

Use the fix’s **Undo** to restore the previous access, then test the workflow again. Nothing is lost by undoing, and you can start watching the route again later.

### Is no traffic during the week proof that the route is unused?

No. Observation with no matches does not prove that a monthly or seasonal task never uses the route. If the route’s owner can confirm it is not needed, closing is safer.

### Which routes should I keep public?

Keep routes public when their purpose requires public use, such as a form that signed-out visitors submit. Ask the integration owner before you restrict a route you do not recognize.

### Is this part of the free plugin?

Yes. Requiring sign-in for a REST API route is part of the free BetterShield plugin on WordPress.org.

## Conclusion

A public REST route is not always a problem, and closing the wrong one is a bigger problem than leaving it open. BetterShield asks you to watch first, closes only the route you pick, refuses nothing but signed-out callers, and keeps **Undo** within reach. That turns a guess into a decision you can reverse.

BetterShield is free on [WordPress.org](https://wordpress.org/plugins/bettershield/). The full steps are in the [REST route access guide](/docs/observe-rest-route/).