Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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)?
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.
