Multi-tenant SaaS search index security: filters, roles and testing
Protect shared SaaS search indexes with server-side tenant filters, scoped index roles, safe writes and tests for results, facets and suggestions.
In this guide
How do you isolate tenants in a SaaS search index?
Search can disclose data even when a user cannot open the underlying record: titles, snippets, counts, autocomplete suggestions, facets and timing can reveal that another tenant's information exists. Choose either a deliberately isolated index per tenant or a shared index with a tenant boundary enforced by the search service and application. Bind tenant scope on the server for every query and test every response path, not only the main result list.
Choose an index model and document its trust boundary
A separate index or cluster can reduce accidental query mixing but adds provisioning, capacity, upgrade and recovery work. A shared index is more efficient, but every searchable document and query must carry a validated tenant boundary. Record which identities can read, write, administer, snapshot and reindex each index, including support and analytics tools.
Attach tenant identity during trusted document ingestion
Set tenant metadata from the authorized source record or event, not from a client-provided field that can be edited. Verify it again during bulk imports, reindexing, replay and backfills. Reject or quarantine documents with a missing or conflicting tenant instead of indexing them into a shared default scope.
Inject tenant filters outside user-controlled search syntax
Derive the tenant filter from the authenticated server context and combine it with the user's permitted query. Do not let a client remove, override or nest a filter in a way that broadens scope. Review saved searches, query templates, dashboard links, autocomplete and administrative search APIs separately.
| Index and data class | Tenant source and mapping | Reader/writer/admin roles | Query surfaces and filters | Cross-tenant negative tests |
|---|---|---|---|---|
| Customer content | ||||
| Tenant analytics or audit index | ||||
| Shared public catalogue |
What search permissions and result paths need protection?
Scope search-service roles to the needed indexes and actions
Separate query readers, ingestion writers, index managers and operators. Restrict index patterns and cluster-wide permissions, and use document- or field-level controls only after validating their documented behavior for your product version. OpenSearch document-level security filters reads; it does not restrict writes, so index permissions must separately prevent unauthorized updates and deletes.
Test aggregations, facets, counts and error behavior
Verify that filters apply to totals, facets, suggestions, highlights, exports and nested or parent-child queries. A result list can hide records while a total count or aggregation still reveals another tenant's activity. Avoid errors that echo protected document text, index names or query values to a different customer.
Treat index snapshots and dashboards as customer data
Limit snapshot and restore access, dashboard sharing, saved objects, analytics pipelines and debugging consoles. A support or observability role that can run an unrestricted query may bypass the application filter. Track who can create cross-index patterns and protect snapshots with the same retention and access policy as source data.
How do you test search isolation through index changes?
Test positive and negative query cases for two tenants
Index similar test documents for tenants A and B, then verify each tenant's results, counts, facets, suggestions and downloads. Repeat for empty filters, malformed tenant context, saved searches, timeouts, partial responses and administrative endpoints. Run tests using the same service identity and role mapping as production.
Protect reindexing, aliases and schema migration
An alias or migration can point a tenant-facing query at a broader index or omit a filter field. Validate document mappings, role patterns, aliases, replica configuration and rollback behavior before cutover. Compare record counts by tenant and block the switch if required tenant metadata is missing.
Monitor query and ingestion paths without logging full documents
Record tenant reference, index, actor, query class, result size, latency and policy outcome while redacting raw search terms or sensitive document content as appropriate. Alert on requests without a tenant filter, unexpected cross-index searches, bulk writes with conflicting tenant values and sudden count anomalies.
SaaS search index security FAQs
Does document-level security protect search writes too?
Not in OpenSearch's documented behavior: DLS filters read operations, while index permissions control index, update and delete operations. Use separate least-privilege writer roles and validate each supported API.
Is one index per tenant always more secure?
It can reduce accidental query mixing, but it is not automatically safer if tenant selection, index aliases, snapshots or operator permissions are broad. Compare the isolation model with operational complexity and test the complete data path.
Can a hidden tenant filter in the user interface isolate search data?
No. Apply the filter in a trusted server or search authorization layer that the client cannot remove. A UI filter is presentation logic and does not restrict direct API calls.
Can search counts or suggestions leak another tenant's data?
Yes. Counts, facets, autocomplete, snippets, highlights and error messages can reveal protected information even when document bodies are hidden. Test each response field and API path with a different tenant identity.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- Document-level securityOpenSearch Documentation
- Defining users and rolesOpenSearch Documentation
- AWS SaaS Storage Strategies: SaaS partitioning modelsAmazon Web Services
- AWS SaaS Lens: Preventing cross-tenant accessAmazon Web Services
- AWS SaaS Lens: Testing multi-tenant SaaS reliabilityAmazon Web Services
- OWASP Cheat Sheet: AuthorizationOWASP Foundation
- AWS SaaS Lens: Tenant-aware operations and onboardingAmazon Web Services
- OWASP Cheat Sheet: LoggingOWASP Foundation