I am planning to use JSON as the data transport mechanism between my iOS app and my server (the server is a WCF service). While learning about JSON, I realized that all the data is passed around directly in the URL. I am sure this question gets asked a lot but I was not able to find anything concrete on the site.

Is there an alternative to sending JSON data directly in the URL?

If not, how do I secure it? I should be able to prevent everyone other than the app from requesting or sending data to the service. One way to do this to be put a 'key' as part of every request; one that is known only to the app and the server. This way I could reject all calls without the correct key. But what is to prevent someone from sniffing the data and forging a request?

Will SSL help here? If I have an SSL certificate, will it automatically encrypt all data to and from the app?

I am sure this is a very common scenario so I am looking for the most elegant way of solving this problem.


2 Answers 2


Not all JSON data is part of the URL's query string. Usually, this is only the case when sending HTTP GET requests to the server.

Services like yours are effectively secured by using HTTPS. The underlying TLS protocol encrypts all data exchanged between client and server, even URL query strings.

If you configure your WCF service(s) to only expose a HTTPS endpoint, all traffic will automatically be encrypted.

Since you mention you're using a WCF service, I recommend having a look at ASP.NET Web API: It's specifically designed to create RESTful services and you'll find it has much less overhead than creating and maintaining WCF services. You'll also get better performance since requests and responses aren't using the SOAP protocol.

  • 1
    Thanks Steven. That was helpful. The reason I am using a service is because I will need the service to initiate iOS notifications. iOS requires a constant connection to be maintained between the Apple notification server and the service. ASP.net web services can shutdown when there are no more connections to it. Yes, there are workarounds but I found the self hosted service to be more graceful.
    – bobbyalex
    May 29, 2014 at 6:41

A key distinction is whether you want (1) to prevent unauthorized users from accessing this API, (2) to prevent eavesdropping or a man-in-the-middle attack, or (3) to prevent unathorized software being used by an authorized user. For (2) you can use SSL. For (1) you can use SSL and have users authenticate using a password. For (3) there is no reliable technical solution, you can only try to obfuscate the API. Encrypting requests using an encryption key embedded (in an obfuscated fashion) inside the program is a common method.

  • I have used Chrome with Postman to see the raw output from Breeze url commands and can't see a way of stopping an authorised user of gaining access to the data. The only way we have managed to stop data being viewed is by linking it to a user login and the server only providing what a user is allowed to see.
    – Oldergit
    May 5, 2015 at 17:07

You must log in to answer this question.

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