Thanks for reading!

That's an interesting point. I did take it for granted that browsers guarantee web apps that they don't send the URL fragment to the server. I've never looked into it, but your comment sent me to read RFC 3986.

From my reading, the RFC does seem to prohibit browsers from sending the URL fragment:

>Fragment identifiers have a special role in information retrieval systems as the primary form of client-side indirect referencing... As such, the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme.

Granted, the wording isn't 100% clear, so maybe I'm imposing my own hopeful interpretation on the RFC.

I agree that if I were storing, say, military secrets, I wouldn't choose the URL fragment as a storage medium. But if the expectation is "this is a place where I can put user data and the browser won't leak it to other places," then the URL fragment seems to me a sensible place to store data, on par with browser local storage.

This is in contrast with plain URLs which third party servers receive through the HTTP referer header. The browser leaks query parameters to other places, too, notably HTTP proxies. But Stripe's JS library was the first I'd seen of a system that exposes URL fragments to an external service.

Putting secret information in a URI is explicitly called out as a bad idea in the very RFC you reference:

> URI producers should not provide a URI that contains a username or password that is intended to be secret. URIs are frequently displayed by browsers, stored in clear text bookmarks, and logged by user agent history and intermediary applications (proxies).

https://tools.ietf.org/html/rfc3986#section-7.5

As an aside, if you're going to be making any security judgments from an RFC, every RFC since RFC2223 has a Security Considerations section. You usually want to start there.

It's fairly obvious that this is about keeping secrets from other users locally whereas the fragment discussion is about keeping secrets from the server and that these two are not the same thing. People reasonably see the fragment as none of the server's business independently of whether it's any other local user's business (the latter fact itself being no one else's business to care about).

Seems like both Stripe and website author are misusing the browser feature.

Seems like core problem is lack of storage API that can only be accessed from JS that's executes from same domain?

Edit: Seems localStorage does isolate per domain, but I am not sure whether it's for page itself or for external JS too.

I've found some places say localStorage is insecure, but both OWASP [0] and MDN [1] say it isolates by origin. Third party scripts from different origins shouldn't be able to access it, but a successful XSS attack could have access.

[0] https://cheatsheetseries.owasp.org/cheatsheets/Session_Manag...

[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage...

Good to know. Thanks for pointing this out!

The fragment is, at the very least, exposed to JavaScript. It's also has several problems which are explicitly called out (for the query string) in your own link: Shoulder surfing, cache, history

This is sort of fair as a statement of principles but I think OAuth2 gets you into the same kind of trouble with special security status for the fragment.

Yes. I’m debating in my head who is correct here. Maybe Oauth2 is colouring my judgement a bit but I feel the fragment should NOT be sent to the server unless there are extremely good reasons. Let’s try to keep the understanding of what happens to certain things consistent even if we have the power to abuse them.

The url has space was username and password, pretty much from day one.