We have a client complaining that there is PII in the browser history (as in the persistent history you get to through your browser's menu - Ctrl + H in Chrome). For example, the URL for editing a user is something like: "https://www.mysite.com/users/USERNAME_HERE/edit". And of course that will show up in your browser history.

Is this really a security concern? What about other PII like order number (for a retail site)?

  • Is there any requirement that the username must be the legal name? A name can be classified as PII, but if it's an arbitrarily selected username that would (should) be on them if they decide to put their real name in there. If I decide to use my social security number as my username, that shouldn't make the website owner suddenly have to hide my username wherever it appears. [obligatory IANAL] – Fire Quacker Apr 23 '20 at 17:32

It really depends on the nature of the website. If the site already shows the username on other places (like here on this site) then it probably isn’t PII. If the username is show nowhere else, then it might be considered PII.

That being said, why is the username exposed in the url for an edit (apart from being the default for certain frameworks)? Especially since URLs are generally logged and saved in history, it is generally considered a bad practice to use usernames because it could give a hacker information about the usernames used in your system. Given this information and the fact that users tend to reuse passwords, the risks are getting bigger than they should be.


Here is a reference on PII that is relevant to the US. But you should do research into how PII is defined and what regulations are relevant to PII for wherever you are operating your site. You may also want to look into the same things where you are allowing users to use the site as you may also be held accountable in those locations.

It also may matter what you use as a username (e.g. Legal name, email address, etc)

It also may matter what industry you are operating within and what service you are providing, in case there are any extra regulations that you must follow.

Your customers trust you to protect the data you are holding, and you should err on the side of caution to avoid losing the trust of your customers.

The way to avoid most of these legal headaches, ambiguity, and security/privacy concerns: for this specific use case, is to use tokenization.

Do not expose data directly in urls (i.e. usernames, keys, identifiers, etc), rather map them to a token in session on the server. This way the numbers become meaningless when you expire the session.

In this case:

/users/bob/edit becomes /users/42/edit


Conceptually yes, anything you disclose that you don't need to is potentially a security risk. It is far easier to guess a password than a username and password. Also plenty of attacks rely on having one or a set of valid user names.

In a web application there is little to no reason to have usernames in URLs, you simply don't need them after authentication. The server knows who is logged in given the session identifier. The user does not need to be informed what their username is. You can use relative references to the logged in user like "session" or "me" or "user" or something and let the server match it to the actual user name if need be.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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