GET vs POST in terms of security

The difference between GET and POST is interface-related, not security-related. A better example for why you avoid GET for non-idempotent operations is to prevent a webcrawler from coming along and innocently making massive changes to your site just by following links. Security-wise, there's little difference between the two, it's trival for the client to change the type of request. (If I can't get some guy on a forum by embedding a picture, I'll send him a link to some website I control where there's a hidden <form> that posts to the site I want.) CSRF is only preventable by putting secret tokens in your forms that get echoed in the submission request (or by double-submitting the cookie as I do, but tptacek will be in here shortly to tell me why that is so silly).

This bit me in the ass once and I learned my lesson.<p>I was working at a social networking startup and I created a Groups feature which allowed users to create their own groups with a forum and a photo gallery and a member list, news feed and so on.<p>Then one day a user sent us an email claiming her group was displaying erratic behavior (users randomly banned, posts randomly deleted, etc). It took us weeks to figure it out, but our ops guy eventually helped us track it down to Google Web Accelerator, which was pre-fetching URLs displayed on the page via GET (links labeled "Ban" and "Delete").<p>This unintentionally effected a similar "Confused Agent" exploit since the app was misusing HTTP in precisely the manor described in this post.<p>Google Web Accelerator has since been discontinued for precisely this reason.<p><a href="http://webaccelerator.google.com/webmasterhelp.html" rel="nofollow">http://webaccelerator.google.com/webmasterhelp.html</a>

The example there is one of a cross-site request forgery (CSRF or XSRF). They pose a solution for POST requests, namely, the "Anti-Forgery Token". This is the right way to stop CSRF on post forms.<p>However, this is a defense which works just as well for GET requests. Just put a nonce in the URL. /do.php?action=delete&#38;id=3&#38;nonce=88e3a6fe57854f2ed18c. Solves it just as well. (Another common solution is to duplicate the session cookie in the URL.) It is not bad form to have a get request which changes state so long as there is a nonce in the URL.<p>Edit: URL was being truncated.

As one of the commenters pointed out, CSRF is just as possible with POST requests as it is with GET requests...

It doesn't matter if you use GET or POST. If you don't sign requests, you don't know where they are coming from.<p>In the API we've implemented recently in our company (e-commerce search-as-a-service) we use request signing exactly according to Amazon's AWS specs.

There are two additional security features POST has that GET does not:<p>1- POSTs cannot be forwarded<p>2- some browsers (webkit only I believe) require a client to interact with a domain before they can POST to it-- this means iframes cannot POST.<p>When it comes to XSRF, they are equally (in)secure.

Don't use GET (&#60;a href="api?deleteId=213"&#62;delete&#60;/a&#62;) requests for operations that are intended to modify content. Some browser plugins follow/crawl links which could inadvertently ruin the users day ;-)

And dont forget the refeerer header that will contain any GET data. I've spoted several sites with this flaw by just looking at the data in my visit log.

This is probably an atypical type of thread for HN but I figured I'd share anyway. It's pretty obvious once you read it but I was a bit curious on the topic regarding SSL/https and sending data via GET. I'd never thought of posting an "image" (or whatever) for an admin to see that could contain harmful data in its URL.