I am new to web javascript development and playing around with apps and scripts for some of the public API's around the web. When a site issues you a unique key to identify your application you code that into your script so you can access the sites API but then anyone who can visit your site can also inspect the source of your JavaScipt so they could see/take/use your API key.
While there's no direct security issue for your own site here, doesn't it mean that anyone else could take my API key and use it for their own app which is completely different? How does one go about making this secure or storing it in a secure way?
What is the best practice in this regard?
Generally API keys are tied to a domain. So even if someone tries to use your key it won't work on any domain but the one for the site it was issued for.
APIs typically offer domain authentication as an alternative to an API secret, for when the API needs to be called from client-side code.
Usually these KEYS are mapped to a domain. So another person's domain will not be able to use your key.
Related
I'm building a Chrome extension using the Remember the Milk web API. In order to call methods in this API, I need to sign my requests using an API key and a "shared secret" key.
My concern is that any user could just crack open the extension and pull out these values if I include them in the published extension. This may or may not pose a security rise for the user, but he or she could certainly use/abuse my API key and maybe get it revoked.
Is this something I should be concerned about? Are there any best practices for protecting this type of information in published JavaScript applications?
Ultimately you can't truly hide anything within a JS application that's run in the browser; you can obfuscate or minify the code, which will distract casual users from snooping around, but in the end its always going to be possible to grab your plaintext secret.
If you really need to prevent this from happening, then one option is to pass calls from your extension to a server you have access to. Your server can add any paramters required for signing, forward the call on to the relevant API, and pass the API's response back to the user. Of course this adds bandwidth / uptime constraints which you may not want.
I want to create an API at www.MyDomain.com that is accessible from public websites www.Customer1.com and www.Customer2.com. These public websites display each customers inventory and do not have any login features. They will use AJAX calls to read data from my API.
How can I secure the API so that it can be accessed via AJAX from different domains but no one can access the API to be able to scrape all of my customers data and all of their inventory?
I have tried thinking of different solutions on my own but they would all either require people to login to the public websites (which isn't an option) or it would require some secret "key" to be displayed publicly in the browser source code which could then be easily stolen.
Any ideas would be greatly appreciated.
Thanks!
P.S. Are their any obstacles that I am going to run into using Javascript & CORS that I need to look into now?
Anything that is accessible without authentication from a browser is by definition insecure, so you can't stop that. Your best bet is to have to have a relationship with the owner of customer1.com and customer2.com - the server apps for those two websites would make an HTTP call to you and authenticate with your service. Going this way also avoids the CORS issues you're talking about.
If you've already designed the client functionality, you can still probably do it without much change to the javascript - have it point to customer1.com for its AJAX call instead of your API, and customer1.com would accept this request and just act as a proxy to your API. Aside from the authentication, the rest of the request and response could just be pass-throughs to your API.
You can use Microsoft.AspNet.WebApi.Cors.
It's just need add ONE line at webapi config to use CORS in ASP.NET WEB API:
config.EnableCors("*","*","*");
View this for detail.
The simplest way to provide a minimum security here is to provide some kind of token system. Each app has its own token, or combination of tokens which it must pass to the server to be verified. How you generate this tokens is up to you and other than being linked to app's access, doesn't have to mean anything.
Provide a way for each API implementer to open an account with you. This way you will know who is accessing what and in some cases you can block/stop service.
For instance, a token can just be an MD5 hash:
7f138a09169b250e9dcb378140907378
In the database, this hash is linked to their account. On each request, they send this token with what they want. It is verified first to be valid, then the request is fore filled. If the token is invalid, then you can decide how to deal with it. Either don't return anything or return an "access denied" (or anything you want).
One thing to avoid is having a single token for everyone, though this can be a starting point. The reason for this is if some unauthorized app gets a hold of this token and exploits it, you have to change the token for everyone, not just the app that somehow leaked the token. You also can't control if someone has access to something or not.
Since you listed ASP.NET, I can also point you to WCF, which is fairly complex but has all the tools that you need to setup a comprehensive web service to service both you and your clients.
I hope this gives you a starting point!
EDIT:
There are security concerns here in the case that someone leaks their token key somehow. Make sure that you setup a way in which the app/your service do not expose the the token in anyway. Also have a flexible way of blocking a token, both by your clients in you, if it so happens that a token is exploited.
I'm building a Chrome extension using the Remember the Milk web API. In order to call methods in this API, I need to sign my requests using an API key and a "shared secret" key.
My concern is that any user could just crack open the extension and pull out these values if I include them in the published extension. This may or may not pose a security rise for the user, but he or she could certainly use/abuse my API key and maybe get it revoked.
Is this something I should be concerned about? Are there any best practices for protecting this type of information in published JavaScript applications?
Ultimately you can't truly hide anything within a JS application that's run in the browser; you can obfuscate or minify the code, which will distract casual users from snooping around, but in the end its always going to be possible to grab your plaintext secret.
If you really need to prevent this from happening, then one option is to pass calls from your extension to a server you have access to. Your server can add any paramters required for signing, forward the call on to the relevant API, and pass the API's response back to the user. Of course this adds bandwidth / uptime constraints which you may not want.
Looking at Twitter OAuth Libraries, I saw this note:
Be cautious when using JavaScript with OAuth. Don't expose your keys.
Then, looking at jsOAuth examples, I noticed that the keys are exposed in the code.
So my question is: How it is possible to not expose your keys when you use an OAuth library in Javascript?
Thanks.
UPDATE: Ok, maybe jsOAuth is not the right library to use, but how it is possible to do authentication with OAuth on a full Javascript web site?
As said in the documentation linked by you:
Written in JavaScript, jsOAuth aims to be a fully featured open source OAuth library for use in Adobe AIR, Appcelerator Titanium and PhoneGAP. In fact, anywhere that javascript can be used and has cross-domain XMLHttpRequests. For security reasons jsOAuth doesn't run in the browser. Browsers are only mentioned here for running the test suite. If you need jsOAuth in the browser, write an extension.
A good answer to your added question is available here:
Secure OAuth in Javascript
The only really reasonable way, right now, to do OAuth 1 in the browser, is to route API-calls via your server.
There simply is no way, as far as I have understood it, around this. If you do OAuth 1.0a calls through JavaScript from the browser -> You will HAVE to expose your consumer secret and access token secret, to at least the end user.
You cannot store these credentials in:
a cookie, the user can find them.
local storage, the user can find them (better than cookie though, since it does not entail sending a cookie back and forth all the time over HTTP)
in javascript, the user can find them (although this is probably your best bet since it is easier to obscure).
If it were only the access token secret that was exposed to the end user, that would be bearable - since it is in fact he/she who have authenticated your application. But losing your consumer secret is really not so hot, it means that your application is eligible for identity theft. I.e someone else could write an app that claims to be your app.
Even if you made it work securely in the browser, you are hampered by cross domain security blocks.
You could also make a script that sends all necessary values and parameters to the server to do the signing with.
The signed URL can then be sent back to the client (browser) that in turn does the actual request.
I have implemented OAuth 1.0a on the Twitter API that way using jsonp requests.
The benefit of this is that the response body is not relayed via your server, saving bandwidth.
That way you can have your cookie and eat it too.
For example, check out this Facebook plugin.
In the client side the API key is clearly visible. What is stopping another user from obtaining this key and using this feature on a different site?
I figured a very naive implementation would be to check the domain the request comes from but things like this are easy to fake.
If I were to create something similar, how would I go about securing the authentication process?
I want as much of this work to be client side, though some form of server authentication will be required surely? Any links or advice would be greatly appreciated.
Update
Similar question about API keys that I found useful.
In three words: server-side validation. FB itself will throw an error when you use a key that's incorrect for the given site. The API key is not supposed to be secret (as opposed to the secret key).
I haven't done this myself, but I know that the kind of attack you are worried about is called Cross-site Request Forgery (CSRF). The Wikipedia article on that gives some hints on how to prevent it.