Is there a way to stop Web Storage and IndexedDB regarding schema to be part of origin?

Question

Web Storage (Local and Session) and IndexedDB are both client side storage mechanisms. And they both quite rightly adhere to the Same Origin Policy. But if I have a web site consisting of http and https pages, that prevents me from reading data written on my http pages in my https pages, and vice versa.

That is the correct behavior, and the reasons for that behavior are obvious, but...

...well, it can be a bit frustrating at times. If I wanted to store non-sensitive data to be available across http and https pages then it would be really nice to be able to do that (without resorting to cookies!).

I don't think there is any way to accomplish that, but I thought I would just throw it out there in case I have overlooked something.

Many Thanks,

Paul

Answer 1

This is a great question, Paul! There's no circumvention of hostname restrictions and you're right to note this is by design.

I would implement your IDB stores on a page served from the secure domain, then talk to it across protocols via postMessage. That way you can use your IDB store on both http and https pages. (Obviously, doing this the otherway around would result in an insecure content warning.)

I've not tried this myself, but had great success sending data back and forth between Web Worker and client so I imagine a postMessage interface not to be much different. Although there's a limitation in what data types you can pass via postMessage, all data in IDB has to be able to be "structured cloned" anyways meaning you can't store functions and such and wouldn't be missing out here.

Answer 2

If https data were able to read by http, it is a weak link in security chain. Cookie api was a mistake. Also there is little reason to use http.