We are thinking of building a REST API where all calls are over SSL. After successful login subsequent calls will include a token which was returned by the login service. The server will validate that the token is legit and valid. Is this considered a valid method of securing an API? What are the risks here?

  • by using SSL, as long as it's a secure version, you are only protecting about data sniffing over the wire. But remember you need to take actions in the server side anyway such as code validation. – Ay0 Feb 11 '16 at 9:59
  • You should look into using OAuth 2.0 along with secure versions of TLS. – jwilleke Feb 12 '16 at 13:58

This assumes many other components of the system are secure. Likewise it doesn't protect the API from direct attack by a bad actor who can register for an account (may or may not be an issue for you). It is also always wise to have in-band protection for connections to any service. Maybe look at something like a Web Application Firewall (WAF) or something like mod_security to add additional controls. Some of it depends on how secure you want things but there are lots of additional security controls depending on your application.

See the OWASP REST Security Cheat Sheet for more information about REST specifically and don't forget to harden your servers and secure your network as well.



I have worked with REST web services that have this same security scheme. This is a good way to secure your web services in my opinion. The only risk that I would like to point out is to be cautious about how much information you are logging when your web services are invoked. Specifically, be careful that the user's credentials are not being stored in some log when the users invoke the authentication web service to receive the tokens. Also, be sure that the tokens are not being logged on subsequent requests. If this information is being logged, then be sure to mask the data.


This is secure if:

  • the attacker can not login (which implies that the entire authentication process must be secure)
  • the attacker can not obtain a valid token (which requires that tokens are kept where the attacker can not get them, and not be leaked by transmitting them)
  • the token verification can not be bypassed and only accepts valid tokens

While (correctly implemented) SSL will guard the token in transit, the token remains vulnerable at the endpoints of the communication, and at any intermediaries doing SSL interception (such as "HTTPS proxies"). Even if these systems are trusted, they can leak the token without intending to, for instance because they log the request (for instance, you better not pass the token in the URL, because that commonly appears in logfiles).

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.