Let me start by saying that putting the decryption key in the URL is generally bad practice. Although, it's fairly common to do it this way for API endpoints that aren't super security sensitive because it's easy to share a URL.
The reasoning is that GET request URLs are often cached and logged by various bits of software and hardware during the request and someone could easily discover the URL in logs. This is why login forms generally do POST requests when sending passwords over SSL connections. The URL of a POST request can still be logged but the payload containing the password will be encrypted over SSL.
That said, I can't be 100% certain from just playing with it but the password functionality does help with this kind of attack. It appears to be decrypting the payload in the browser after fetching the encrypted data from the server.
IIRC fragments don’t go to the server on GET requests, either, so that helps in this scenario. I’m guessing that’s why they chose fragments instead of query params to house the decryption key
The first part of the URL after the ? is the query parameter. This part of the URL is sent to the server to identify the encrypted data.
The part after the # is the fragment. Historically this was used to identify part of the page so the browser could scroll to it when the link was clicked. Later, it got hijacked by modern JavaScript frameworks for all sorts of purposes.
Indeed, I admit my mistake, putting the decryption key in the fragment is safer. Although, personally I'd still be more comfortable using a password (e.g. hello).
#in the URL. For anyone wondering how this works let me explain. Here's an example URL.?is the query parameter. This part of the URL is sent to the server to identify the encrypted data.#is the fragment. Historically this was used to identify part of the page so the browser could scroll to it when the link was clicked. Later, it got hijacked by modern JavaScript frameworks for all sorts of purposes.hello).