By John

2008-11-27 08:18:50 8 Comments

I am creating a secure web based API that uses HTTPS; however, if I allow the users to configure it (include sending password) using a query string will this also be secure or should I force it to be done via a POST?


@Ruchira Randana 2016-03-28 06:52:42

Yes, your query strings will be encrypted.

The reason behind is that query strings are part of the HTTP protocol which is an application layer protocol, while the security (SSL/TLS) part comes from the transport layer. The SSL connection is established first and then the query parameters (which belongs to the http protocol) sent to the server.

When establishing a SSL connection, your client will call the following steps in order. Suppose you're trying to login to a site named and want to send your credentials using query params . Your complete URL may look like the following.

  1. Your client (e.g: browser/mobile app) will first resolve your domain name ( to an IP address ( using a DNS request. When querying that information, only domain specific information is used. ie: only will be used.
  2. Now, your client will try to connect to the server with the IP address and will attempt to connect to port 443 (SSL service port not the default http port 80).
  3. Now, the server at will send its certificates to your client.
  4. Your client will verify the certificates and start exchanging a shared secret key for your session.
  5. After successfully establishing a secure connection, then only will your query parameters be sent via the secure connection.

Therefore, you won't expose sensitive data. However, sending your credentials over an https session using this method is not the best way. You should go for a different approach.

@zaph 2016-03-28 12:11:43

But see the answer by @dr. evil, the quarry string may end up in log files and caches so it is may not secure on the server.

@Ruchira Randana 2016-03-28 12:18:28

Hi zaph, in terms of HTTPS security, the objective is to send data securely to the server without anyone in the middle being able to sniff out the data. While that is possible, and answers the question, it's really difficult to control what the server does afterwards. That's why I've also mentioned this is not the correct way. Adding to that, you should never send ur password from the client. You should always hash it on the device and send the hash value to the server.

@zaph 2016-03-28 12:25:11

From a security standpoint sending confidential information in the quarry string is not secure, it is best to send it in a POST. Also the password is generally hashed on the server, not by the client. The statement "you should never send ur password from the client" is in conflict with the answer: (e.g

@James W 2018-05-23 03:42:28

@RuchiraRandana hashing on client is pointless because the private key is then easily retrieved from the front end.

@curiousguy 2018-07-18 13:54:24

@JamesW "the private key is then easily retrieved from the front end" What key?

@James W 2018-07-27 02:58:17

@curiousguy yeah good point. And having the hasing algorithm doens't enable the "unhash" of the thing itself. And hashing it on the front end limits MITM attacks. My Mistake for some reason i had hash and encrypt on the brain mixed up

@Drejc 2008-11-27 08:24:56

Yes, from the moment on you establish a HTTPS connection everyting is secure. The query string (GET) as the POST is sent over SSL.

@Amareswar 2012-11-08 02:00:56

You can send password as MD5 hash param with some salt added. Compare it on the server side for auth.

@slawek 2014-11-28 17:10:48

MD5 is not suitable hash function for passwords.

@Brian Peterson 2014-12-08 04:36:17

But this sounds like a good idea.

@Thomas 2016-04-26 09:29:06

Whether hashed or in cleartext, it is bad practice to send passwords within GET parameters. Please refer to the top voted answer for explanations. Aaaand... MD5 should not be used anywhere anymore...

@curiousguy 2018-07-18 13:55:54

"not suitable hash function for passwords" Still better than sending passwords in cleartext to the server, lol

@shoosh 2008-11-27 08:24:36

Yes. The entire text of an HTTPS session is secured by SSL. That includes the query and the headers. In that respect, a POST and a GET would be exactly the same.

As to the security of your method, there's no real way to say without proper inspection.

@JoeBloggs 2008-11-27 11:01:55

There's more to security than just the communication between browser & server

@dr. evil 2008-11-27 09:11:34

Yes, it is. But using GET for sensitive data is a bad idea for several reasons:

  • Mostly HTTP referrer leakage (an external image in the target page might leak the password[1])
  • Password will be stored in server logs (which is obviously bad)
  • History caches in browsers

Therefore, even though Querystring is secured it's not recommended to transfer sensitive data over querystring.

[1] Although I need to note that RFC states that browser should not send referrers from HTTPS to HTTP. But that doesn't mean a bad 3rd party browser toolbar or an external image/flash from an HTTPS site won't leak it.

@Jus12 2013-10-29 08:12:10

What about https to https referrers? If I am getting an image from a 3rd party site using https? Will the browser send the entire query string from my previous request to the 3rd party server?

@dr. evil 2013-11-12 13:21:34

@Jus12 yes it'll, it doesn't make sense but that's how it's designed.

@gihanchanuka 2015-10-02 07:31:29

Then why is that OAuth2 specification isn't recommend to send sensitive data in query parameters (in the URL) ? Even though it's recommend to use TLS (HTTPS) always. Refer to the last point in‌​3 CC @volka

@Lijo 2016-08-18 02:55:12

@dr.evil Could you please elaborate what is the issue with History caches in browsers or add some reference for ir?

@Tom 2016-08-20 22:25:52

To complete that answer with up to date infos :… ( Proxy PAC hack allows for intercept of HTTPS URLS )

@James Wierzba 2017-02-13 22:14:48

I believe most platforms require all resources on a page to use https if the page is requested using https (at least in .NET)

@Arthur 2018-06-05 00:08:51

The original question states he is creating an API. So server-to-server calls. How is referrer leakage or browser history even relevant here? Regarding server-side logging of GET parameters; a server admin may just as well (accidentally) have enabled logging of POST parameters; so one can argue if that really makes much of a difference? I would advise in general to be in control of your server environment, whether that means disabling logging of GET parameters for certain requests, or making sure logging of POST parameters is disabled.

@GaTechThomas 2019-03-29 17:11:00

@Arthur it never says server to server. API's are called all the time from browser.

@Arthur 2019-03-29 18:54:22

@GaTechThomas it doesn't literally say that in the question; however he is talking about including a password in the calls. To me that doesn't sound like an API to be used from the client browser; otherwise you are exposing the API password to all clients.. (then it doesn't matter if it is included as GET or POST parameter)

@GaTechThomas 2019-03-30 13:38:42

I see. Sending password to the API server is such a thing of the past that I didn't comprehend that that was the intent. You're right. For others reading this, the question is good for understanding URL visibility, but the overall approach should be reconsidered.

@Ali Afshar 2008-11-27 11:17:52

Yes, as long as no one is looking over your shoulder at the monitor.

@Rahul Prasad 2012-11-12 10:39:44

and your browser not saving the history :)

@Arnout 2008-11-27 09:40:29

I don't agree with the statement about [...] HTTP referrer leakage (an external image in the target page might leak the password) in Slough's response.

The HTTP 1.1 RFC explicitly states:

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

Anyway, server logs and browser history are more than sufficient reasons not to put sensitive data in the query string.

@JoeBloggs 2008-11-27 11:04:40

There's that word 'should' again. Would you trust every version of every browser with your password?

@Arnout 2008-11-27 14:59:29

How exactly is this related to GET vs POST? Would "every version of every browser" be safe if you're using POST over HTTPS?

@AviD 2009-04-04 21:36:59

Besides, the HTTPS web page might be retreiving an external image over HTTPS - in which case, the browser SHOULD include the referer header, and thus expose your password...

@Andy 2011-10-25 13:59:39

@Arnout: Please read this RFC which tells you what SHOULD NOT means: Its NOT the same as MUST NOT, so the part you quoted isn't really relevent and browser agents might still include a referer to HTTP.

@Aaron Digulla 2008-11-27 08:45:19

SSL first connects to the host, so the host name and port number are transferred as clear text. When the host responds and the challenge succeeds, the client will encrypt the HTTP request with the actual URL (i.e. anything after the third slash) and and send it to the server.

There are several ways to break this security.

It is possible to configure a proxy to act as a "man in the middle". Basically, the browser sends the request to connect to the real server to the proxy. If the proxy is configured this way, it will connect via SSL to the real server but the browser will still talk to the proxy. So if an attacker can gain access of the proxy, he can see all the data that flows through it in clear text.

Your requests will also be visible in the browser history. Users might be tempted to bookmark the site. Some users have bookmark sync tools installed, so the password could end up on or some other place.

Lastly, someone might have hacked your computer and installed a keyboard logger or a screen scraper (and a lot of Trojan Horse type viruses do). Since the password is visible directly on the screen (as opposed to "*" in a password dialog), this is another security hole.

Conclusion: When it comes to security, always rely on the beaten path. There is just too much that you don't know, won't think of and which will break your neck.

@Pieter 2015-11-17 15:18:58

"the browser will still talk to the proxy" not quite true, it will need to present the browser with a valid certificate that the proxy can only generate if it has control over a CA the browser trusts.

@VolkA 2008-11-27 08:29:42

From a "sniff the network packet" point of view a GET request is safe, as the browser will first establish the secure connection and then send the request containing the GET parameters. But GET url's will be stored in the users browser history / autocomplete, which is not a good place to store e.g. password data in. Of course this only applies if you take the broader "Webservice" definition that might access the service from a browser, if you access it only from your custom application this should not be a problem.

So using post at least for password dialogs should be preferred. Also as pointed out in the link littlegeek posted a GET URL is more likely to be written to your server logs.

Related Questions

Sponsored Content

33 Answered Questions

[SOLVED] Query-string encoding of a Javascript Object

22 Answered Questions

[SOLVED] How to get GET (query string) variables in Express.js on Node.js?

13 Answered Questions

[SOLVED] Are HTTPS URLs encrypted?

  • 2009-01-31 21:15:34
  • Daniel Kivatinos
  • 237875 View
  • 880 Score
  • 13 Answer
  • Tags:   ssl https httprequest

73 Answered Questions

[SOLVED] How can I get query string values in JavaScript?

7 Answered Questions

[SOLVED] Enabling HTTPS on express.js

3 Answered Questions

[SOLVED] What is the maximum possible length of a query string?

34 Answered Questions

[SOLVED] How to build a query string for a URL in C#?

4 Answered Questions

[SOLVED] Are querystring parameters secure in HTTPS (HTTP + SSL)?

11 Answered Questions

[SOLVED] Is it secure to submit from a HTTP form to HTTPS?

  • 2008-11-08 03:00:07
  • Tai Squared
  • 32757 View
  • 72 Score
  • 11 Answer
  • Tags:   security https

9 Answered Questions

[SOLVED] https URL with token parameter : how secure is it?

Sponsored Content