Cross-Tenant Authorization Regression Testing for AFH Software

Multi-facility adult family home software must make switching between facilities easy without ever carrying residents, medication orders, reports, files, or permissions across the wrong boundary. Tenant isolation is proven by adversarial testing at every data path—not by a facility selector in the sidebar.

This guide covers software security and verification, not a claim that one database architecture guarantees compliance. It was reviewed on August 8, 2026. Providers should evaluate authorization, privacy, contracts, risk, and operational controls for their environment.

Define the tenant and every subordinate boundary

For most AFH workflows, the facility or licensed organization is the primary tenant context. Under it may sit:

• Residents
• Caregivers and assignments
• Medication orders and MAR events
• Pharmacy relationships
• Documents and reports
• Appointments and incidents
• Notifications and support conversations
• Billing and subscription records

Document whether a multi-facility owner has one portfolio identity with separate facility grants or a different model. Never infer access from ownership of another facility.

Derive context from authenticated grants

The server should bind active tenant context to the signed-in identity and current facility assignment. Treat facility IDs from query parameters, request bodies, headers, local storage, and UI state as untrusted selectors that require authorization.

The OWASP Multi-Tenant Security guidance recommends establishing tenant context early, validating ownership at the data-access layer, and applying isolation to caches, sessions, APIs, files, and lifecycle operations.

Do not let internal functions skip validation merely because the request originated from another trusted service.

Test direct object references

Provision Facility Alpha and Facility Beta with distinctive synthetic data. As a Beta-only user, attempt to read, update, export, or delete Alpha resources by substituting:

• Resident IDs
• Medication and order IDs
• Document IDs
• Report job IDs
• Pharmacy submission IDs
• Notification IDs
• Caregiver IDs
• Support-ticket attachments

Expect a consistent denial that does not reveal whether the target exists. Hiding the link in the interface is not authorization.

Automate these tests for every endpoint and role after schema, query, cache, or router changes.

Enforce tenant filters at the data layer

Every query and write should include verified tenant scope. Use repository or policy abstractions that make unscoped access difficult and reviewable.

Add defense in depth where the platform supports row-level security, separate schemas, or databases. Regardless of architecture, integration and administrative paths still need explicit tenant checks.

Test joins and subcollections. A resident may be scoped correctly while a joined medication or document query omits the facility condition.

Isolate cache keys

Include tenant, user or role context, resource, filters, and version in cache keys. Validate ownership again when returning sensitive cached data.

Test identical resident IDs or query terms in two facilities. A cached search, dashboard count, medication catalog preference, or report must not return the first tenant's result to the second.

Clear or partition personalized caches on facility switch and sign-out. Public terminology caches can be shared only when they contain no tenant or resident information.

Test facility switching thoroughly

When a user changes the active facility:

• Cancel in-flight resident queries
• Clear resident-specific form validation
• Invalidate facility-scoped search results
• Refresh notifications and counts
• Close or relabel drawers and dialogs
• Reauthorize open record routes
• Preserve safe unsaved generic fields only when intended
• Block submission under the prior context

A late Alpha response must not render after the UI displays Beta. Tag requests with context version and discard stale results.

For pharmacy users, show the active facility in every resident and medication-order screen and revalidate it on submission.

Isolate files and signed URLs

Storage paths should include opaque tenant scope, but paths alone are not sufficient. Authorize every upload, preview, download, replacement, and deletion on the server.

Test whether a signed URL created for Alpha remains usable by an unauthorized Beta user or beyond its intended time. Use short-lived, purpose-bounded delivery and avoid public buckets.

Document previews, generated PDFs, thumbnails, and quarantined uploads all require the same boundary.

Isolate queues and background jobs

Queue messages need explicit tenant identifiers verified against source records. Workers should query and write within that scope, then record it in the run ledger.

Test malformed messages that name an Alpha resident with a Beta tenant. The worker should reject and audit them rather than choosing one field as authoritative.

For portfolio-wide scheduled jobs, process each facility with separate checkpoints and exception isolation. One tenant's failure or volume should not leak data or block all others.

Protect reports and exports

Authorize both report creation and download. Store the facility, resident filters, requesting user, permission snapshot, query version, and data-through time with the job.

Recheck current authorization before delivering a delayed export. If a user's facility access was revoked while rendering, do not email or expose the finished file.

Test empty and broad filters. A missing facility filter should fail closed, not become “all facilities” except through a specific platform-authorized workflow.

Test pharmacy relationship boundaries

A pharmacy may serve many facilities. Model each approved pharmacy-facility relationship independently with status, permissions, and dates.

The pharmacy can search residents only within the active approved facility. A medication order submission validates pharmacy organization, facility relationship, resident ownership, and submitting user.

Regenerating an access PIN, ending one relationship, or switching facilities must not affect another approved facility relationship or expose its residents.

Test role combinations inside a tenant

Tenant isolation does not replace role authorization. Within one facility, verify owner, manager, caregiver, read-only, pharmacy, support, and other roles against each action.

Use an authorization matrix covering read, create, update, amend, export, delete, restore, assign, and administer. Test role demotion and revocation while sessions and tabs are open.

The caregiver access permissions guide explains least-privilege facility assignments and historical authorship.

Protect search and autocomplete

Search indexes must carry tenant and authorization metadata. Filter before ranking, not after returning the top results.

Test partial names, misspellings, empty queries, recent items, and browser history. No suggestion count, highlighted match, or timing difference should reveal another facility's resident.

Shared medication terminology search can remain tenant-neutral; recent prescribers, local compounds, resident names, and pharmacy orders cannot.

Test administrative and support access

Platform administrators and support tools need explicit, auditable elevation rather than an unbounded backdoor. Require a case or reason, time limit, narrow facility scope, and visible activity record.

Do not let support impersonation bypass storage, export, or audit controls. Test that support access ends when the elevation expires and that tenant users can receive appropriate transparency under policy.

Break-glass access should be rare, monitored, and reviewed.

Monitor isolation signals

Alert on:

• Authorization denials for cross-tenant object IDs
• Requests with conflicting tenant fields
• Unscoped query attempts
• Cache ownership mismatch
• Queue tenant/source mismatch
• Export delivery after revocation
• Storage prefix mismatch
• Pharmacy submission outside an approved relationship
• Support elevation outside its case window

Use opaque identifiers in security logs. Do not copy resident data into monitoring systems.

Treat every isolation denial as a testable security decision, but distinguish expected regression traffic from suspicious production behavior. Test suites should carry a signed run identifier and use synthetic tenants; production monitoring should rate-limit repeated probes, preserve source evidence, and route serious patterns through the incident-response process.

Re-run targeted cases after changes to database indexes, collection-group queries, storage rules, cache libraries, report generators, background workers, or role mappings. These changes can bypass an otherwise unchanged page-level authorization check.

Run a release isolation suite

Test at least:

1. Alpha resident URL requested by Beta user.
2. Alpha medication update with Beta token.
3. Search after rapid facility switch.
4. Stale response arrives from prior facility.
5. Cached dashboard key collision.
6. Document ID substitution.
7. Delayed PDF after access revocation.
8. Background message with conflicting tenant and resident.
9. Pharmacy relationship ended for one facility only.
10. Role demoted while two tabs remain open.
11. Bulk action with mixed-tenant IDs.
12. Deleted-item restore across facilities.
13. Public terminology cache contains no tenant content.
14. Support elevation expires during use.
15. Database backup restore preserves tenant scope.
16. Logs and error pages reveal no foreign record detail.

Run the suite against APIs directly, not only through the browser.

Frequently asked questions

Is hiding other facilities in the menu enough?

No. Enforce tenant and role authorization on every server read, write, file, queue, search, and export path.

Can a multi-facility owner share one login?

One identity can hold separate explicit facility grants. Every request still resolves and verifies the active facility boundary.

Should tenant IDs come from the request body?

They can select context, but the server must validate them against authenticated grants and source-record ownership.

How should a pharmacy switch facilities safely?

Use an unmistakable active-facility boundary, clear resident-specific state, cancel stale queries, and validate the relationship and resident again on submission.

What is the strongest isolation test?

Seed two tenants and deliberately request the other tenant's objects through every API and storage path. The result must deny access without disclosing record existence.

Make facility switching convenient and provably safe

Strong tenant isolation derives context from authenticated grants, enforces it at data access, partitions caches and files, validates queues and exports, and continuously tests direct cross-facility attacks.

Explore AFH Manager to test multi-facility switching, pharmacy relationships, resident search isolation, report authorization, revocation, and cross-tenant regression coverage with synthetic facilities.