Hi I've been wondering what you guys think is good practice for developing an application utilizing REST/JSON while being very cautious of the data being transmitted. If my application is going to work with patient data and I have a GET using a generic URL similar to http://srvr.com/patients I want to be certain that a user A who has a list of 5 unique patients and user B who has a list of 5 unique patients can never see each other's data using any sort of URL tricks or session hacks. I'd definitely try to control cookie and sessions to control that but am curious about other techniques with headers, etc. What about encrypting JSON and perhaps decrypting it on the client side. Is this even necessary?
I'd rather be safe than sorry and I'm sure somebody is using JMVC behind authentication with HIPAA or other private data and has some input on this.
Yeah I didn't mean to say this is a problem specific to JMVC. But knowing that JMVC utilizes REST I was curious if anyone could shed light on how they combat that issue. If simply using https is the solution then I have my answer. I wasn't sure if that was sufficient or not. This was the remaining obstacle I had between using JMVC (or any other REST approach) and perhaps another. Just curious, has anyone written an application where the data needed to be protected using JMVC and if so are there any other bits of advice?
Sorry to be confusing Justin. I'm certainly not making myself clear enough. I use HTTPS on all of my projects but work exclusively with a server side language to authenticate and validate my requests. I've been enamored with switching to a more client side approach - I want to switch :)
I'm more asking about the best way to authenticate a specific request to secure my API.
Maybe a real world example would help. How does a site like Grooveshark, upon my logging in, return my playlists dynamically? I assume they have a http://grooveshark.com/playlist -- sure -- but they must pass some credentials identifying ME to the API so that the response is specific to me.
So that having been said, I'm not looking for how it is actually done. I'm asking if there are any special concerns I need to have (other than HTTPS) and if for example, headers, cookies, etc are the answer for authenticating those requests.
I hope that clears it up and if not, well, I'll probably just find a more appropriate forum.
I just don't understand why rest would make a difference between what you were doing and using REST. You should still be using a server side language to authenticate and validate your requests (likely by a token sent by a cookie).
Grooveshark undoubtedly passes a token in a cookie on every request.
So ... there are no special considerations for REST base services. Your server should be doing what it always has been doing, but instead of sending back HTML, it sends back JSON.
Quite honestly I thought this was the approach I should be taking but I was being conservative and thought I'd consult the experts first. I appreciate how quickly you've been responding to my posts. It's very impressive.
Perhaps once I get what I'm trying to do working I'll share my experience as much as I can.
OWASP is one of the most useful and reliable sources regarding all things web security. SSL and a token validation scheme is a good start but it's only that, a start. Writing a web application it's up to you to write code that isn't vulnerable to cross-site scripting attacks, SQL injection and other nasty stuff.