I'm being forced to send data via GET (query string) to another server.

For example: =%7B%22date%22%3A%222011-03-01T23%3A46%3A43.707Z%22%2C%22str%22%3A%22test%20string%22%2C%22arr%22%3A%5B%22a%22%2C%22b%22%2C%22c%22%5D%7D 

It's a JSON encoded string. However, anyone with half a brain can see that and decode it to get the underlying data.

1. I understand that the query string is limited in length
2. I don't have a choice about using GET vs PUT/POST

Is there a way for me to encode a lot of data in a much shorter string that can be decrypted from the server? (using javascript)

I suppose HTTPS doesn't actually resolve this since the data is in the uri?

I'm being forced to send data via GET (query string) to another server.

For example: http://myserver./blah?data=%7B%22date%22%3A%222011-03-01T23%3A46%3A43.707Z%22%2C%22str%22%3A%22test%20string%22%2C%22arr%22%3A%5B%22a%22%2C%22b%22%2C%22c%22%5D%7D 

It's a JSON encoded string. However, anyone with half a brain can see that and decode it to get the underlying data.

1. I understand that the query string is limited in length
2. I don't have a choice about using GET vs PUT/POST

Is there a way for me to encode a lot of data in a much shorter string that can be decrypted from the server? (using javascript)

I suppose HTTPS doesn't actually resolve this since the data is in the uri?

• javascript
• json

• 1 I'm not sure I understand the requirements, but: PUT/POST don't make any difference in terms of security: it just means somebody would look in a different place to see it. And HTTPS encrypts the connection, not just the response. – Ken Commented Mar 2, 2011 at 0:00
• I cannot send a PUT/POST request due to same-domain policy on ajax requests. I'm limited to using a GET request to send data to my server encoded in the query string. – john Commented Mar 2, 2011 at 2:32

3 Answers 3

HTTPS resolves it -- even the data in the HTTP header (including the URI) is protected, since the whole connection happens over an SSL channel.

There is one exception: the host name will be exposed if the client uses a proxy, since it is transmitted in the clear in the CONNECT request.

Given your constraints, the only option I see is to use a public key / private key pair, like PGP does, where the public key is used to encrypt data (which you'd then send via GET), and the private key is used to decrypt it. At that point you'd probably have left JSON behind (although you could certainly set up the data as JSON, then encrypt it, and send the result as a Base64-encoded string or something). Note that this doesn't protect you from false messages (as the public key is, well, public), but it does mean that people couldn't read the data in transit without the private key.

• HTTPS is indeed a solution for protecting your data. It first creates a secure connection to the server (via TLS) using IP address and port. -then all the HTTP packets are sent over this connection encrypted. ( Is GET data also encrypted in HTTPS?)

• The practical limit for URL length seems to be somewhat around 1000 chars ( What is the maximum length of a URL in different browsers?)

• And there are quite a couple of pression snippets around... ( JavaScript implementation of Gzip)