I am currently developing a tiny web app. Since username/password would be too much of a overhead I am thinking of a GET param for authorization and authentication.

Example: funnydomain.rocks/lol?secret=some_random_hash

Just to be sure, I am not asking if this is secure, since it is not. I am asking for the risk of using it. How big is the chance that someone else will use this to "login". I am fine with recovering my database once a year and changing the hash for each user. Much less effort than using username/password, especially with my kind of users...


  • limited amount of users (no more than ten)
  • each user receive its own hash
  • SSL is used
  • URL and secret will be bookmarked in several browsers (and saved in some cloud services)
  • d̶a̶t̶a̶ ̶i̶s̶ ̶n̶o̶t̶ ̶w̶o̶r̶t̶h̶ ̶p̶r̶o̶t̶e̶c̶t̶i̶n̶g̶ data is not critical

1 Answer 1


If you're using HTTPS/SSL and you trust your endpoints, this is fairly secure for your purposes, because the get parameter will be encrypted as part of the query string, so traffic capture is not a problem.

The "secret" hashes will most likely end up in the web server logs of the web server which servers your web application, but if you control these logs, then for your level of desired security that's probably a non-issue.

You'll obviously also have to trust all the services which store these URLs (browser bookmarks, cloud services etc, but you seeem to be fine with that). I'd think the greatest risk was here (e.g. one of your users logs in using a public computer, and the next user of that public computer looks at the browser history, clicks the link and has access to your protected data).

If you're using unencrypted HTTP, your secret hashes will also end up in proxy server logs and basically anyone who can eavesdrop on your connection will have tons of chances to capture the secrets.

However, I'd only do direct GET param authentication if I really didn't care much about the secrecy and integrity of the data the secret hashes are supposed to protect (basically if I wanted to keep the hordes of stupid vandals at bay, but didn't think any determined person might be interested enough in my data to try to access it, and didn't have a problem if it turned out I was wrong).

A very simple way to considerably improve the security of your authentication scheme would be to have the secret tokens expire, or even better yet, to treat them as one-time-passwords. Give each user a list of tokens, to be used one after the other. This doesn't require much code on the server side and solves the problem of one of your users accidentally leaving/publishing his secret token somewhere.

  • Thank you for your answer, I will accept it shortly. Just to be sure, if I use the param as in "funnydomain.rocks/lol/some_random_hash" the hash would be captured right? Therefore I need the syntax of "?secret=etc"
    – 0lli.rocks
    Mar 2, 2017 at 11:38
  • 1
    No, in both cases, when using SSL, the path and query string are encrypted, so are invisible to eavesdroppers. In fact, nothing much besides the target ip and port is known. OTOH, at the source and target, both path and query string can be seen. So it doesn't make a difference, except maybe that some search engines might not try to index urls containing a ? Mar 2, 2017 at 12:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .