PRACTICAL FIELD GUIDE
Frontend filtering is not an access-control boundary
A hidden row in the UI can remain accessible through a direct API request. Enforce private access at the backend and treat frontend filtering only as presentation.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Inspect the underlying list and single-record endpoints without relying on the app's screen logic.
- Apply the intended owner policy or trusted server authorization.
- Test direct requests as another user and anonymous caller.
What this looks like
ILLUSTRATIVE EXAMPLE
The interface filters tasks by owner locally, but the API returns everyone's tasks first. The hidden rows are already exposed to the browser.
A boundary to keep clear
Do not consider an obscure record ID sufficient protection. Authorization must be checked for the requested operation.
MCPBackend context
MCPBackend row policies apply to anonymous callers and end-user tokens. Machine API keys bypass those row policies and are instead constrained by their own table permissions. Owner mode is based on the calling user's identity; it is not an organization-membership or arbitrary custom-policy engine.
Take the next step
Inspect the current project contract, try the change with disposable data, and verify the result through the same credentials your app will use. Record the expected response and one denied-access case before release.
Sources and further reading
These references explain the underlying protocols and design principles. For supported MCPBackend operations and exact request shapes, inspect your project’s generated API contract.