6

I'm about to develop a new API for our website. Part of the design I've considered to use the POST and GET methods but after reading some security stuff I realise that GET is a bit less secure(i.e. allows hotlinking) than POST.

So my question is why people use GET in an API if is less secure? Is it just a legacy conception that "GET" should be used to read and POST to write (i.e. forms). The GET method still makes sense to me for an image URL or a website page which you can bookmark but does it make sense for an API? Using the same method (i.e. POST) would make the API more consistent too as you don't need to worry about the method.

I should mention that I don't want to argue against the HATEOS/RESTful thing because I'm planning a RPC api (i.e. like twitter, facebook etc).

  • I just came across this question and I am facing a very similar situation. I'm thinking of doing a POST-only API where all input is a JSON string and all output is a JSON string. It's not strict RESTful, but it's easy to fire curl requests at the server and it's consistent. I notice (I looked briefly) that Twitter only use the GET and POST verbs for their API and don't use any others. I haven't seen any convincing argument about why I should use strict RESTful. I'm open to debate on this. It reminds be of the "never use HTML tables" types from 10 years ago. – Eamorr Jun 7 '15 at 19:06
  • @Eamorr how did you implement this, can help me with the same. URL: stackoverflow.com/questions/47646924/… – Mr Robot Dec 5 '17 at 6:15
  • GET requests show up in the logs - which is a problem for shops constrained by HIPAA rules (PHI/PII security). So many companies resort to just using REST. – Bob Husted Oct 7 at 21:13
4

So my question is why people use GET in an API if is less secure?

People often think using POST requests are a solution to CSRF but POST requests are still vulnerable and if CSRF prevention is your goal then you should implement a CSRF token.

However, CSRF is not usually considered a threat to an API because the fundamental premise of a CSRF attack (ie. one site making a request to another without human action) is actually the intention. To give a really simple example, a malicious site which submits a form to mybank.com/transfermoney works because the user already has an authentication cookie set for mybank.com. However, if an AJAX request was made to mybank.com/transfermoney it wouldn't work because the cookie won't be sent and therefore the user won't already be authenticated.

To authenticate with an API you usually have to pass something like an authentication token/key which an attacker would have to know, compared to the other example where the attacker didn't have to know the cookie value to invoke an authenticated action.

With regard to GET vs. POST, if you're trying to achieve a RESTful interface then GET and POST have different functions. GET should be used for retrieving (reading) a resource, whereas POST should be used for submitting a new one.

  • The api may be used by the users too(i.e the end user) though various auth schemas(cookies or headers). Another point i made is that the get requests can be hotlinked which may drain your resources – The user with no hat Mar 22 '15 at 14:35
  • as far as RESTful is concered I already mentioned that i'm not planning to achieve that and rather to develop a half baked RESTful api I was wondering why should I bother with the GET request if it's less secure too. – The user with no hat Mar 22 '15 at 14:38
  • @Theuserwithnohat what he's saying is, nothing is secure if you don't implement any proper authentication measure. You'll also probably drain your resources if you only use POST as all responses won't be cached. – imel96 Mar 23 '15 at 0:17
  • 1
    @Theuserwithnohat I misinterpreted what you said about REST, nonetheless POST is not materially more secure than GET. You should favour semantic reasons for picking GET or REST, and if CSRF is a threat then use a CSRF token instead of relying on POST for security. – thexacre Mar 23 '15 at 7:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.