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


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


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.

| improve this answer | |
  • 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 1 '13 at 13:37
  • 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

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.

| improve this answer | |

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.

| improve this answer | |

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