0

We have a web-based application in which we are not requiring end users to login. The application uses Ajax to make calls to REST services hosted on the same server. Besides this application, we want to make sure that if any other applications / agents call the REST service they get denied.

What is the simplest way to secure a REST API like this? My guess is that we would include some sort of security token and make the call through HTTPS. However I'm not clear how the Ajax application would create/obtain/encrypt the token and generally what the lifecycle looks like.

I would rather do this outside of Spring Security or OAuth if possible. I have also read that sending username and password over SSL is enough for authentication. In this case, the app would have a "username" and password and it would send it with every request to the REST service. But how would it keep that information secret if the client is just HTML and javascript in the browser?

Thanks.

pastafarian
  • 1,010
  • 3
  • 16
  • 30
  • possible duplicate of [Best Practices for securing a REST API / web service](http://stackoverflow.com/questions/7551/best-practices-for-securing-a-rest-api-web-service) – Marc B Aug 31 '11 at 21:12

1 Answers1

0

In general this is impossible. Someone could just do view source on your javascript, read the token, then do whatever they want.

https is not necessary here. For the token, probably the easiest is to set a cookie when they download the javascript from the server, then that cookie will also be transmitted with any AJAX requests.

This is not really secure - anyone can just see what the cookie is and use it, but it's the best you can do.

Ariel
  • 25,995
  • 5
  • 59
  • 69
  • The answer given to http://stackoverflow.com/questions/5511589/securing-an-api-ssl-http-basic-authentication-vs-signiture seems to indicate SSL is necessary to encrypt the cookie (preventing MITM attack). I am fine with putting a security token in the header or a cookie. In this scenario, I am just not sure how an unsecured page would securely obtain the token in the first place? – pastafarian Aug 31 '11 at 21:21
  • 1
    I'm unclear about what you are trying to secure, and I think you are too. All an attacker would need to do is download the javascript - https or not, and they have the cookie. Now that they have the cookie they can send whatever they want to the REST service, and you can do nothing about it. Stopping MITM attacks is a completely different thing and will do nothing whatsoever to make sure "if any other applications / agents call the REST service they get denied" - the other application does not need to MITM, they can just call the service directly themself. – Ariel Aug 31 '11 at 21:27
  • 1
    Thanks. I think perhaps I worded the question vaguely. I want to make sure of 2 things: 1. no one can just download the code form the browser and be able to fake a call to the service as if it's coming from an approved Ajax-enabled application and... 2. no one can sniff the wire and obtain authentication information in-transit. (hence the need for SSL) – pastafarian Aug 31 '11 at 21:33
  • Goal 1 is impossible. Goal 2 is pointless since you said people don't need to login. If you need to secure the service you need to do it on the server end. – Ariel Aug 31 '11 at 21:36