Typesense Scoped Search Keys Are Only as Strong as the Parent Key
Typesense can generate scoped search keys that embed filters for a tenant, user, or document field. The client cannot remove the embedded filter. That makes scoped keys useful for browser and mobile search, but the design depends on the parent key and on the data model. A scoped key created from an administrative parent is a control failure waiting to happen.
Use a search-only parent
Typesense documentation says scoped search keys must be created from a parent key whose permissions are limited to documents:search. The bootstrap API key can create keys and administer the server; it should not be embedded in application code or used to sign frontend scoped keys.
Create a dedicated parent search key for each environment or tenant boundary when practical. Store it on the backend, generate the scoped key there, and return only the short-lived derived key to the client.
Make the filter authoritative
A scoped key can embed filter_by, exclude_fields, and result limits. The filter should refer to a field the application cannot forge. If tenant access is based on a mutable document field, an indexing bug can place one tenant's record in another tenant's result set.
Review the ingestion path that populates the access field. Test a document with a missing or malformed tenant value. It should be excluded by design, not returned because the filter does not match the expected schema.
What the ZoomEye observation shows
The count-only queries used sub_type=all, page 1, and page size 1. app="Typesense" returned 0, title="Typesense" returned 383, and http.body="Typesense" returned 3,114.
The zero application result is valid. The title and body values are inventory evidence, not proof that an instance allows public search or exposes an administrative endpoint. A documentation page can contain the product name without running Typesense.
Use the counts to compare public references with owned search deployments and cloud records. Do not test extraction or authentication against unknown instances.
Review the key lifecycle
Record the bootstrap key owner, parent search keys, derived-key generation service, expiry policy, and revocation process. Do not allow an old tenant key to remain valid after a user leaves unless the application has a documented cache and expiry design.
The Typesense documentation notes that a collection-scoped search key may expose data from referenced collections through joins. Review joined collections as part of the same tenant boundary. A safe filter on the primary collection can still leak a related record if the join path is not constrained.
Test negative cases
Use a test tenant and verify that a forged filter cannot override the embedded condition. Search for a record owned by another tenant and confirm it is absent. Try an excluded field and confirm it does not appear. Remove a user's access and test the key after the intended expiry.
Monitor search volume, key generation failures, and unusual queries. A scoped key is a capability, not an authentication session. Its blast radius is determined by the parent key, the filter field, and the data indexed behind it.
Top comments (0)