3

I have an application that currently keeps a few properties from a user's profile in session storage for the app to use when necessary. We don't keep sensitive data like username or password or ssn in session storage, but we do keep properties like the user's branch there. And the app uses the branch info to load certain data, while excluding other data. For instance, if a user's branch is "New York" then we load data relevant to that branch.

To clarify further, this is an in-house app -- behind a VPN -- so only employees will be using the app. And we let them temporarily change their branch in the app itself if, for instance, they're in the New York branch but want to see data from Los Angeles.

Is using session storage like this considered a reasonable practice, or should something like this always be stored in something like JavaScript storage? I have one colleague who seems to think this should definitely not be in session storage, but I'm not sure that's the case here. Is this considered a major no-no in this kind of use case? Or could this be considered a reasonable usage of session storage?

  • Keep in mind if you are storing on the client, the user is able to modify it. Perhaps they could access other branches that they shouldn't have access to. As far as where to store things on the client, I think it depends more on your duration needs. – multithr3at3d Nov 12 '18 at 13:57
  • Thanks. To clarify, this is an in-house app. So only employees would be accessing it. We're not concerned about them being able to switch their branch. In fact, we let them do that in the app itself. If they, for instance, want to see data pertaining to "Los Angeles" and they're branch is "New York" -- we let them do that by temporarily changing their branch to "Los Angeles". – Muirik Nov 12 '18 at 14:04
0

Probably the biggest concern I would have with this is scalability. It is unlikely that the web server language you are using is storing session variables in any kind of optimized database. So if you are only planning on storing a few short variables for a few concurrent sessions, I would say this is a great way to do it (I've used it in some of my applications). As far as security goes, storing variables on server side as opposed to client side is always preferred.

0

Security wise is not a concern in my opinion.

The data stored there is not sensitive and I understand that if is modified it does not allow the user to access restricted data and they can do the change in the application itself. If the application checks server side that value - there is no security concern. That being said, the principal idea behind the security of sessionStorage is that you have to treat it as untrusted. This means validate it, encode it, escape it before usage and do not use it for sensitive data.

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.