I'm on a dev team where the product manager wants to allow internal users to "impersonate end-user and show the site exactly as the user sees it". I argue that this raises security flags and, even if it is allowed, data should be obfuscated and the UI should be read-only. When I call my bank or phone company for tech support, can they impersonate me?

Googling "where can I discuss web application data security" leads to white papers and product web sites rather than forums or discussions.

Is impersonating an end user something that should be allowed, and if so how should it be done? How can it be done without loosing data integrity?

  • With two down votes and no comments, it doesn't help me make this question better. How can I make this question better?
    – flipdoubt
    Commented Jul 15, 2021 at 13:12
  • 1
    I personally do not think this question is that bad. Too broad, perhaps, but not a terrible question. It certainly has implications for software engineering. I attempted an answer. Commented Jul 15, 2021 at 13:16
  • 1
    If impersonation means going into the production system on the user's account I would readily agree that there are some issues with that approach. But I guess that's not what the product manager wants. There is no need for that, a personal account for the internal user that gas the same profile and access right seems enough to help out a remote user. Commented Jul 15, 2021 at 16:09
  • 1
    Impersonation is a common (and necessary) feature of many "enterprisey" authentication frameworks. Unix has the venerable su (switch user) and sudo (execute command as a different user), Windows has runas, and whatever the name of the authentication framework is that goes together with ASP.NET, I am sure, it has it too. There are legitimate reasons for impersonating a user, debugging a user issue being one of them. Note that it is pretty much impossible to prevent it, because someone has physical access to the server, the network, the build infrastructure, etc. pp. Commented Jul 15, 2021 at 16:44
  • 1
    It should, however, also be noted that it is vital to have a) proper security and privacy training for those persons with the privilege allowing them to impersonate users, and b) proper audit trails of whatever actions are done while impersonating a user. Which is why, e.g. sudo is preferred over su because a) it prints a short lecture when using it for the first time, and b) it provides auditing. Commented Jul 16, 2021 at 15:52

3 Answers 3


This is in fact quite common, but I don’t believe there is a general guideline, as the details depend upon each situation. But there is at least a couple of key points to remember.

There are two kinds of impersonation, in production and in development. In a complex environment, where you have multiple user roles and abilities, impersonation in development is very close to being a requirement IMO. If you have dozens or hundreds of things that one user can do but another can’t, developers and testers need to be able to “be” a particular user with all of their permissions and nothing more. Even if the only distinguishing features between users is their data, it’s still useful in development as it’s a quick and easy way to get at just the data that is relevant.

In production there are 2 key things to keep in mind, accountability and data privacy.

Impersonation doesn’t have to conflict with accountability, just because you allow someone to do everything that someone else does, doesn’t mean that you can’t record who actually did it. Auditing data might show E, E on behalf of U or finally just U. The last should be avoided as it does muddle accountability. Given your bank example, it would be fine if the bank records show that Employee555 transferred money from your account to another, and totally unacceptable for the record to show that flipdoubt did the transfer.

Data privacy, your impersonator should be someone that already has the ability to look at the data anyway. The ability to impersonate shouldn’t be something that all employee’s should have. This should be kept in mind when determining what internal roles are going to be doing the impersonating. In your development environment, any necessary data obfuscated should be done regardless of impersonation. If you don’t want developers to see it in development, it shouldn’t make it to your development environment.

I will note that my bank does give what could be considered an “impersonation” it uses OAuth (I believe) to allow me to give a 3rd party site read only permission to my account. So do several of my credit card accounts. I mention this not only because of your bank reference but because it provides another model to consider : access but only with permission.


Typically this is not accomplished by impersonating another user. Instead, customer support staff are granted permissions to modify customer data. Any modifications should record the date and time of modification, and who modified it. Recording information about who and when data is modified is critical in cases where something didn't go right, whether by accident or by malicious intent.

Depending on how critical the data is, destructive actions, like overwrites and deletes, should be prevented. Any modification of data should result in a new row being inserted with some duplicate data. Any removal of data should be accomplished with a "soft delete" where you set a status flag to "deleted" or "invalid." This allows for full transparency in the customer support process, and makes all data changes reversible.

When support is required on an end-user device, a remote desktop application, or some kind of virtualization software is used to connect to the device as yourself (the support technician). Support staff should not be connecting as the end user. Your argument about raising security flags is justified.


You are right. But what you manager really means is "if a user has a bug or problem I want to be able to reproduce it so I can help them solve it"

I would recommend you setup a number of test users with varying scenarios. Locked out, Zero balance, Cancelled Order, whatever this should enable you to check those scenarios for bugs and to check what the screens look like if you get a customer with that same setup.

You should also have an admin interface for helping customers which allows you to take various actions. But not as that user, as a customer support guy. So cancel order, take payment, fire rearward facing missile, whatever.

Additionally you should be able to check the logs realtime and filter by user so you can see what they are actually doing vs what they say they are doing along with any errors etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.