I didn’t know the part after # in a URL doesn’t get sent to the server.
While that is technically true, please know that it is not true in a way that is meaningful for many threat models. The JavaScript running on the page can trivially detect, inspect, and log changes to the location hash.
Isn’t this true of any client side site? If the client side JS has access to some information, it’s always possible for the server to inject custom JS that returns the data. Theoretically this setup provides little additional security but it does allow (for example) people to use a client pinned to a version they’ve verified to not leak information and collaborate without worrying about leakage. (Excalidraw developer here)
Thanks for the interesting post. This isn’t a critique or evaluation of your work and you did mention that the client side JS can read the location hash.
I agree with your comment. I just don’t want anyone to think that a key stored in the location hash is somehow truly protected from ever getting back to the server, which was how the comment to which I responded sounded to me.
While that is technically true, please know that it is not true in a way that is meaningful for many threat models. The JavaScript running on the page can trivially detect, inspect, and log changes to the location hash.
More information here:
https://developer.mozilla.org/en-US/docs/Web/API/WindowEvent...