I would like to use session storage to query user data in the database only once and then simply use JS to retrieve it, so I'm thinking about using session storage. My question is next, is that safe?

Please note:

1. JS can't be inserted to pages with forms (forms only accept alphanumeric values) so it can only come from URL

1.1 Query strings like www.website/?q=blablabla are not used in php (php doesn't retrieve any data from url)

1.2 Calling js in url with javascript:script... isn't a big concern since the user can only asccess his own data, not to mention that he can already access it - that's the point of user data

1.3 Is there a third way of a user being redirected to the site via a link that contains JS that will than be able to access session storage? i.e.: somthing like - www.website/script...

My guess is that only something like 1.3 would be a threat (in addition to that, am I missing something?) but does that even exist? And if so is there a way to prevent it?

Thanks for your time and replys.

I would like to use session storage to query user data in the database only once and then simply use JS to retrieve it, so I'm thinking about using session storage. My question is next, is that safe?

Please note:

1. JS can't be inserted to pages with forms (forms only accept alphanumeric values) so it can only come from URL

1.1 Query strings like www.website.com/?q=blablabla are not used in php (php doesn't retrieve any data from url)

1.2 Calling js in url with javascript:script... isn't a big concern since the user can only asccess his own data, not to mention that he can already access it - that's the point of user data

1.3 Is there a third way of a user being redirected to the site via a link that contains JS that will than be able to access session storage? i.e.: somthing like - www.website.com/script...

My guess is that only something like 1.3 would be a threat (in addition to that, am I missing something?) but does that even exist? And if so is there a way to prevent it?

Thanks for your time and replys.

• javascript
• session
• html
• storage
• xss

• Please elaborate what you mean with "safe". I assume you mean "how good is it protected against malicious JavaScript reading it from other pages"? – chiborg Commented Apr 20, 2011 at 9:42
• @chiborg that is exactly what I mean - I know that even if the JS reached session storage, it would need to know the key value. Furthermore session storage is tied to a domain. The problem is the key can be eventually guessed. Therefor I think safety mostly relies on the session storage being tied to the domain (hence the worry about 1.3 from my post). – AppBuilder Commented Apr 20, 2011 at 11:31

2 Answers 2

You're essentially relying on two things for session storage security:

1. The browser limiting access only to the javascript on the page from this domain
2. javascript that is running on the page to be secure

Now there's not a whole lot you can do about No. 1 because that's the vendor's issue and, not pointing at anyone in particular but, most of them are usually pretty good at this kind of thing.

So you can be fairly sure no other code on any other tab, domain, browser or process is going to be able to see your storage object.

However, No. 2 is more difficult, You'll have to evaluate by yourself how secure your page is to script attacks, there's plenty of documentation out there on best practices but you could go on for days. You really need to judge how sensitive the data is versus how much work and possible loss of features it would be to secure against it.

If it's really sensitive data I'd question why you'd risk storing it client side at all and have access only through HTTPS. But you're site should be secured for most scripting attacks because if 3rd party javascript is running session cookies are up for grabs and therefore your server security is compromised too.

Since the session storage can only be read by JavaScript that is running on your page, I think your question boils down to "How can JavaScript be excuted/inserted into my page?" There are two attack methods: XSS, meaning some way to inject JavaScript into your page through posting data to your site. If this data is not filtered, it may insert script tags or JavaScript events into your HTML. There are many ways to do this and to protect against it, so I can't be more specific.

A lesser threat would be to trick the site into displaying or changing information through specially crafted links that call specific actions on your page. This technique is called CSRF. Example: Someone crafts a link to the "change email" page and tricks a user who is logged into clicking this link, this changing the email info in the session storage.

If your application is public, anyone can open the session storage in his browser and look up the names of the keys. So unless they are randomized obscurity offers no protection here.