When developing Webpages, they say you should use POST for "destructive" actions, and GET for actions that only retrieve information.

Is the same true for apps? Is it a total no-no to use GET for sending requests from an iPhone app over HTTPS to a Web server for actions such as:

  • Creating games
  • Updating scores
  • Sending messages

(None of the actions are actually "destructive", none of the server functions DELETE anything, though some UPDATE things like high scores, which may be considered destructive since they overwrite stuff.)

I have backups in case of data loss, but I'm asking regardless of this.

3 Answers 3


The point about "destructive GET" is that attackers may make some victim users unwillingly send such "GET" requests. This is simple: the attacker just has to include, on his Web site, an <img> tag pointing at the target URL. The victim's browser will then perform the fateful GET.

That normal requests come from an application, and not a browser, does not change this fact. The problem is not from where normal requests come, but what abnormal requests can do.

What you could imagine is to make your application add some application-specific HTTP headers, which the server verifies, and that a basic Web browser would not set in a normal GET. But then, you do not really have a "normal GET" any more. It seems simpler, safer and less hackish to simply use POST requests for anything which may be destructive (including data updates); or, even simpler, POST requests for everything. If the client is a custom application, it should have no reason to prefer GET requests over POST.

  • I already send a random-generated session parameter which is unique for each user. But how is POST more secure than GET in an app environment, where there is no browser involved with multiple tabs that can trigger <img> tags and such?
    – forthrin
    Aug 26, 2013 at 21:11
  • Unfortunately, even if your application is no browser, attackers don't feel restrained that way. If they can convince a victim's browser to make a GET, they will. Where there is an "app", there is a platform which can run apps, and such platforms can also run Web browsers, and their authentication cookies can even be shared (which is your problem, really). Aug 26, 2013 at 21:13
  • How is authentication cookies shared between app and browser? Doesn't the app use a network environment that is completely encapsulated from the browser?
    – forthrin
    Aug 27, 2013 at 7:35
  • If your app authenticates using it's own isolated cookie jar or isolated authentication session, it shouldn't be vulnerable to any CSRF from the browser. Aug 27, 2013 at 9:15

Just to add to Thomas Pornin's answer, GET requests are subject to caching by proxy servers so you can't 100% guarantee that a GET request will make it to the target server and not get the response from a proxy. Yes you can add headers to specify that there is to be no caching, but not every proxy abides by the rules. Isn't it easier to use best practise and POST your updates? I can't see why you would want to use GET (apart from laziness). By using POST you are informing everything (browser / HTTP provider, proxy and server) that the request makes a "destructive" change and it should ensure your request is made appropriately without the need to manage any request headers.

Also, POST requests are less likely to have parameters logged so any sensitive parameters on the query string in a GET are not likely to be stored outside of your application's control such as in proxy or server logs (e.g. tokens) when made in the POST body instead. Again this isn't guaranteed, but by using the appropriate request method you are hinting at the intention of the request.

  • Actually, the downside of using POST is that you can't use the Web server log for checking traffic anymore. You have to log the POST data from your server code, and information about GET and POST will be in two different time-sorted files. Actually, I would personally have like int/enum variables in the Web server log whether they were POST or GET, and binary/text variables to be discarded. All for brevity and legibility during debugging. But I'm probably rambling.
    – forthrin
    Aug 27, 2013 at 12:16

Adding to Thomas answer, you should always remember to make your app check the certificate received in the ssl handshake.

It is YOUR job, as a mobile developer, to correctly verify if the certificate is valid (if your server uses a self-signed one, be sure to pin it inside the app), or your users will be prone to MITM attacks and BAD things tend to happen in those scenarios. Users love free wifi...

You must log in to answer this question.

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