How To Require Sign-in for a Selected REST Route With BetterShield?
Observe a public REST route before requiring sign-in, review who uses it, and undo the restriction if a legitimate workflow needs it.
With BetterShield, observe a public REST route before requiring sign-in, review who uses it, and undo the restriction if a legitimate workflow needs it.
What it does
A finding about a public REST route can offer a guided fix. BetterShield observes use before requiring sign-in for the route you choose. This is a targeted restriction, not a switch that disables the entire WordPress REST API.
Step 1: Open BetterShield › Findings
Open the route finding under BetterShield › Findings and review its evidence.
Step 2: Require sign-in for a selected REST route
- Select Require Sign-in for the selected route to start observation. Allow the full week to include scheduled and infrequent integrations.
- Read the observed use and proposed scope. Test forms, apps and any external front end that calls it.
- After the week of observation, select Close to Visitors only when that route should not answer signed-out callers.
Recommended settings
Keep routes public when their purpose requires public use. Ask the integration owner before restricting a route you do not recognize.
What it can break and how to undo
A signed-out app, public form or headless front end can lose access. Use the fix’s Undo to restore the previous access and test that workflow again. Observation with no matches is not proof that a monthly task does not use the route.
Final Outcome
Test the chosen route signed out and with the intended signed-in account. Confirm other routes still behave as before, and read the activity entry for the change.
This is how you can require sign-in for a selected REST route with BetterShield.
Getting Stuck? Feel free to contact our Dedicated Support Team.