Control Support Impersonation

A support worker who “logs in as” a customer can inherit more authority than needed. The system may also record actions as if the customer performed them. That hides who made a change. Design support access as a distinct mode with approval, limits, and visible identity. OWASP Authorization supports contextual grants and least privilege.

Support-access record

The UI should show when support mode is active. Audit events should identify the staff actor and the customer tenant. Do not make them look like routine customer actions. For exports, role changes, and other sensitive effects, consider a separate approval even when read-only support access is permitted.

Test the limits

Create two synthetic tenants. Approve a narrow A support case and verify that the staff account can perform only the named action. Request B data, attempt an A member role change, and try again after expiry. Each denied action must leave records, jobs, and messages unchanged. Inspect the audit event to confirm it names the staff actor, target tenant, purpose, and decision without storing private content.

The OWASP Logging Cheat Sheet supports useful event evidence and sensitive-field exclusions. This support record is the artifact. It makes an exception to normal tenant isolation testable, but it is not a blanket grant. If the product cannot separate staff and customer identities in audit, use a safer support path rather than describing impersonation as controlled. Keep these tests in an owned environment or exact written scope.

Record the customer-visible consequence of a staff change. A support action that updates a record may trigger email or audit notifications. Those outputs must identify the staff mode accurately and must not imply the customer made the change themselves.