Tyler Close and others who did the security architecture for Waterken did the relevent research form this. They use unguessable strings in URI fragments as web-keys:
This leakage of a permission bearing URL via the
Referer
header is only a problem in practice if the target host of a hyperlink is different from the source host, and so potentially malicious. RFC 2616 foresaw the danger of such leakage of information and so provided security guidance in section 15.1.3:"Because the source of a link might be private information or might reveal an otherwise private information source, … Clients SHOULD NOT include a
Referer
header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol."Unfortunately, clients have implemented this guidance to the letter, meaning the
Referer
header is sent if both the referring page and the destination page use HTTPS, but are served by different hosts.This enthusiastic use of the Referer header would present a significant barrier to implementation of the web-key concept were it not for one unrelated, but rather fortunate, requirement placed on use of the
Referer
header. Section 14.36 of RFC 2616, which governs use of theReferer
header, states that: "The URI MUST NOT include a fragment." Testing of deployed web browsers has shown this requirement is commonly implemented.Putting the unguessable permission key in the fragment segment produces an https URL that looks like:
<https://www.example.com/app/#mhbqcmmva5ja3>
.Fetching a representation
Placing the key in the URL fragment component prevents leakage via the
Referer
header but also complicates the dereference operation, since the fragment is also not sent in theRequest-URI
of an HTTP request. This complication is overcome using the two cornerstones of Web 2.0: JavaScript and XMLHttpRequest.
So, yes, you can use fragment identifiers to hold secrets, though those secrets could be stolen and exfiltrated if your application is susceptible to XSS, and there is no equivalent of http-only cookies for fragment identifiers.
I believe Waterken mitigates this by removing the secret from the fragment before it runs any application code in the same way many sensitive daemons zero-out their argv
.