At 9/26/14 09:53 AM, yoloswag69 wrote:
The key is called "cookies". When you emit a "Set-Cookie" header browsers will automatically pass that variable back to your server.
You're right that HTTP can always be intercepted, because you would have to use math tricks to share a key with a server in a way that can't be intercepted. Fortunately this stuff is also automatically handled by servers and browsers: secure connections.
If you're using a service like Heroku or Azure to host your server , you can just change the URL to "https:" and a secure connection will be used. Now your interchange is not interceptable.
I'm not sure I fully understand. To store a cookie I need to run some client side JavaScript, which is just vulnerable, no?
My imaginary API worked like this: devs sign up, are given a key, that key is used to allow them to access only data specific to that key. I had no idea what this "API" would do (i.e. what data I was going to store), only the way devs would interact with it.
The problem was that in an Angular app, all requests are made "client-side". So if you make the request in Angular via the http module:
$http({url: "samsgreatapiurl/somethingelse", method: "GET", key: "my dev key"})
The devs server does none of the requesting, no preprocessing is done, so the key is essentially plain text to any user of the app.
I spoke with a developer at work and the solution we came up with this. As a dev and user of my super cool API, you can either:
Inject the key into the request via something like an Apache module or run some server script to route the requests, and add the key there.
It shouldn't be my concern if the developers adequately secure their key.