13

It's the first RESTful web service and I am concerned about security issues. Is it safe to transmit my access token via HTTP headers? For example:

POST /v1/i/resource HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Api-key: 5cac3297f0d9f46e1gh3k83881ba0980215cd71e
Access_token: 080ab6bd49b138594ac9647dc929122adfb983c8

parameter1=foo&parameter2=bar

The connection made over SSL. Also, What is need to be defined as the scope attribute for every access token

yannis
  • 39,547
  • 40
  • 183
  • 216
ahmedsaber111
  • 233
  • 1
  • 2
  • 5

3 Answers3

17

If you were to transmit access token header through HTTP, then it would be vulnerable to the man-in-the middle attack.

When you transmit access token header through HTTPS, then nobody apart from the client will be able to see this token as the request will be tunnelled through secure connection.

CodeART
  • 3,992
  • 1
  • 20
  • 23
  • 4
    A sloppy client may be vulnerable to MITM attacks even with SSL. – ott-- Aug 31 '13 at 20:43
  • Can you provide an example please? – CodeART Aug 31 '13 at 21:47
  • You can't guarantee client side security if you don't control the client, but that's true of just about anything. – Matt Aug 31 '13 at 22:21
  • 2
    @CodeWorks Most browsers will offer the user the opportunity to connect to an HTTPS resource even if the SSL certificate is wrong for the resource. This is, arguably, one of the dumbest things browser authors have ever done, and it is essentially offering to accept MITM attacks. – Ross Patterson Sep 01 '13 at 13:37
  • @RossPatterson Unfortunately, a necessary evil to enable hardware network traffic inspectors, which are often required by a company's security policy (and in certain circumstances, by law). These devices are performing MITM for "good", by design. Whether or not there is a better way to perform stateful inspection by a trusted network device on encrypted traffic remains a topic for another day. ;) – Dan Apr 18 '16 at 18:08
  • 1
    @Dan then that *specific* MITM certificate should be added to clients' root cert list. Otherwise you've reduced the HTTPS warning to a literal "cry wolf" that both A) trains your users to forever ignore it, B) is difficult (impossible because of A) to tell apart from a real, malicious MITM attack. – Nick T Jan 31 '17 at 18:25
  • @NickT I don't think users should ever ignore it. The bypass feature needs to exist for test and development reasons, and modern web browsers (at least Chrome / Firefox) make it sufficiently difficult to "accidentally" click past, in my opinion. I suppose it could be disabled by default and only allowed via some hidden setting (e.g. chrome://settings), but the warning is usually bright red, requires multiple clicks, and outlines the potential negative consequences pretty clearly. If you hide the setting better, adamant abusers will still find it. You can't fix stupid. – Dan Jan 31 '17 at 18:49
  • Just to be completely clear, are you saying this is true of headers in general or is there something special about calling the header "Access_token" that makes it more secure? I mean, the API you are communicating with will expect it to be called a certain thing, but if they had called it "the_candy_store_across_the_street", would this still be secure? – still_dreaming_1 Dec 06 '19 at 15:31
8

There are no serious issue in transferring access token over http headers because transferred data is encrypted when SSL is used, means it can be understand only by particular client which made that request and server who responses for the request, in between there are no chances to understand the data by any third party.

Other thing is access token are time based so they have a life for a specific period so they have no chances of use in future.

Ashwin
  • 181
  • 4
-1

A thing to consider also is caching.

Your backend could see several calls to same URL, with same GET/POST parameters but a different header access token and consider content can be cached and severs to any body.

Thomas Decaux
  • 111
  • 1