PocketBase API rules are access control, including the empty rule
PocketBase API rules are access control, including the empty rule PocketBase combines an embedded SQLite backend, a dashboard, authentication collections and a REST-ish API. Its API rules documentation gives each colle
PocketBase API rules are access control, including the empty rule
PocketBase combines an embedded SQLite backend, a dashboard, authentication collections and a REST-ish API. Its API rules documentation gives each collection five actions: list, view, create, update and delete. Auth collections also have a manage rule. A rule set to null is locked to authorized superusers, while an empty string permits anyone. Those two values can look similar in a configuration review but mean very different things.
On 2026-11-05, a count-only ZoomEye query with sub_type=all, page 1 and page size 1 returned 67 matches for app="PocketBase". The broad title query returned 125. The counts locate candidate services; they do not show which collections exist or how their rules are configured.
Rules are filters and policy at once
PocketBase documentation says API rules also act as record filters. A list rule can return an empty list when a request does not satisfy the filter, while view and mutation failures produce other status codes. This behavior can make a misconfigured rule look quiet during a shallow check. Test the actual response body and status for each action, and test as a guest, an ordinary authenticated user and an administrator.
The superuser distinction is critical. The documentation states that superusers can access and modify anything, ignoring collection rules. A dashboard account is therefore not a normal application user with a few extra fields. Protect it with a strong unique credential, MFA where the version supports it, network restrictions and a separate administrative path. Do not reuse the superuser token in an application deployment.
Build a rule baseline
Export the collection schemas and rules into a reviewable baseline. Check every empty rule and every rule that references request data without a clear ownership condition. The default locked state is safer than an accidental public rule, but a feature that fails after a review may tempt an operator to open the collection broadly. Prefer a written exception with an owner and an expiry date.
PocketBase Web APIs are stateless in the sense described by its documentation: requests carry an authorization token, and the server does not maintain a traditional session to revoke. If a token leaks, clear it from clients and rotate the relevant secret or user credential. Plan the invalidation path before an incident. A dashboard logout is not a universal revocation mechanism.
Back up the database, configuration and rules together. Test restoration in an isolated instance, then verify that authentication and collection rules still behave as expected after restoring. An exposed backup can contain user records and credentials even if the live dashboard is protected.
The ZoomEye measurements are an inventory lead, not a claim that the sampled servers are unauthenticated. Use them to check public listeners, rule behavior and administrative exposure. If a collection returns unexpected records to a guest, preserve the request and response metadata, fix the rule, then review other collections that use the same pattern.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes โ full credit and traffic to the original publisher.