I use some of Azure's Cognitive Services via JavaScript on my website. How can I avoid that anybody grabs the key and uses up my quotas? Other API providers I've worked with allow the user to limit the key to certain domains but I just can't find such a setting in the Azure backend.
How can I avoid that anybody grabs the key and uses up my quotas?
Open door: Don't put your key in a plain text readable file.
Whatever JavaScript trickery you want to use, the code is available. So the key is out there.
Obvious answer: Keep the key server-side and solve it this way. Yes, it's an extra trip. But you can beef up the filtering of requests a lot more. Like you said, you could fake a host. So use this to make sure nobody is using up your quota.
"I still want it clientside" then Steven Legett has some ideas for you.
USE HTTPS!
Related
I have an iOS app in which I use parse.com as backend service. Now, I hired someone to do a website interface using HTML and CSS. I want to share the same data between iOS app and website, I know parse.com offers me a few ways to do this, including creating a javaScriptapplication. The problem is, my programmer doesn't have any experience in JavaScript, nor do I.
My question is: Is it possible to use what I have (objective-c, xcode) as far as retrieving data from parse.com and showing on website? Even if I need to code something new, is it possible to use objective-c together with HTML and CSS?
Thanks.
Parse has several APIs, one of which is REST. Your web developer should use the REST API to get data from Parse
https://www.parse.com/docs/rest
If there is will there is way, but you'll be making something really specific to your use and will be non standard and will be immediately hard to maintain, I recommend that you hire another developer and do things properly using the technologies given to you by parse !. if the cost will be high now I can promise you it'll be much higher if you went the path you're going to now.
So my answer is:
Yes, everything is possible and no, don't do it ! :)
Edit: Added an example to a possible way to do it to actually answer OP's question.
Example case:
1-Create a simple Mac Application in Xcode that fetches data exactly like you do it on iOS, and store the needed data into a database of your choice on your server
2-You now have access to the data you needed from parse, but on a local mirror. you will need some tool to fetch that data though, I recommend a simple PHP script.
Note that this will require an OSX server to always be running to fetch that data, you'll also need of find a way to fetch data on demand when a user needs it Vs. polling at specified intervals, this will hardly scale and will be costly as I said.
Is it possible to extract a website safebrowsing info by javascript? This can be with Google Safe Browsing API, is there any code, or any article?
Related to your comment: This is not a code repository. You'll need to do your own development.
Back to your question: I would like to warn you that you will be exposing your API key to the general public when using javascript (as it's a client-side technology). Furthermore, you're opening the door to abusers. In the end, your "secret" API key might get suspended by Google quicker than you think.
In short: it could be done using the GET request examples the API documentation provides, but if I were you, I would think twice if javascript is really the best option you have.
So I'm working on some mobile application that will represent WordPress page.
Working it like web page, then spreading it to all mobile platforms using phonegap (mainly just taking webkit, moving all his functionalities, and putting that small webpage to applications)
Web is written in jQuery/JavaScript/html/css.
I come to some security problems. All data on original WordPress site is secret, and only members can see stuff from there.
And I need to get data in JSON format.
And there is my problem. :)
I can install (i did install) JSON api, and i can get every bit of data I want. But the problem is that anyone can (just type some "get" stuff in URL (for example: mysite.com/json/get_post/?id=1)).
I need to "secure" that data, and let it go only if the user who is asking for it is logged in.
What is the best solution?
I know there is a lot of security problems in this stuff. And only some encryption would be useful. But I need quick and easy solution that will at least make it harder than just typing url. :)
I found something about oAuth, but didn't really understand the way to use it. Any ideas? Any WordPress plugin? Anything?
Thank you. :)
What you are describing is an OWASP A4 - Insecure Direct Object Refernce vulnerability. Encryption does not solve this problem and is by no means the right tool. The problem is use access control. The user needs to login to the wordpress install in order to gain this type of information. Wordpress has a session system built in and you'll have to read up on their API documentation.
How do I hide my private API keys in/for my webOS - Enyo based apps?
My development has basically come to a halt because of this issue.
Since webOS Enyo (as well as Mojo) is coded in Javascript, any user can plug their device in and easily view my source code. So obviously I can't just stick my keys in there. Even if they are encrypted, my app would have to include the mechanism for decrypting them to make any use of them. I'm looking to hide my private web service API keys (mainly OAuth Twitter, Facebook, Google, etc.) and maybe my AWS private keys.
So far the answers I found have stated that you can't secure anything like a private API key in Javascript. But all of those discussions have been dealing with web applications which have easy alternatives to using Javascript. webOS apps don't really have a pretty alternative to coding simple apps in Javascript.
The only path I see possible is to create a proxy that all of my API calls would pass through. Is that the only feasible or ideal option? If it is, would node.js do the trick for me here?
Any leads, resources, examples, tips, etc. would be greatly appreciated. I feel like the answer should be starring me in the face since so many apps connect to these services nowadays, but I have had no leads. Thanks.
No application of any kind that has client-side private keys like this (other than one that is entirely server-wide) is safe from prying eyes. This is true of a compiled C++ app for Windows too. If the application is going to use the private keys directly, then they're in the code or available to the code. Prying eyes can find them. Yes, Javascript might make the code a little more accessible, but this not a problem that's new to webOS or Javascript apps. If Enyo was a PC/Mac cross platform tool, wouldn't you have the same issue with your Twitter keys?
Usually, what is done is the keys are put in some sort of storage mechanism at install time. On a PC, that might be the registry or some config file. Does webOS have an install mechanism? It looks like they have HTML5-type storage - can you store them in there at install time. They won't be hack-proof (nor would they be on any other platform), but they also won't be lying in your Javascript code either.
The other solution to this is to require your developers to get their own keys to public services like Twitter rather than everyone using your own. That keeps you from risking your whole platform when there's one bad customer.
If I've misunderstood your situation, feel free to clarify and help me understand better.
My feeling is that having a proxy is a great idea. The proxy gives you additional benefits of adding user authentication and other functionality without changing the client side.
Take a look at the Key Manager service, which you can use to store your keys without having to code them into your JS files.
I'm thinking of implementing my web application in a certain way as an optimization, and I'd like to get people's opinions on whether this is a good idea or not.
Here's the details:
For most of my pages, instead of determining server side whether the user is logged in, and then modifying the page I send based on that, I want to send the same page to everyone, this way I can make use of my reverse caching proxy and for most requests not even have to run any dynamic code at all.
The differences that need to be done for logged in users will be done in javascript. The necessary information to make the changes (what their user name is, their user id, and if they are logged in or not) will be stored in a cookie that can be read by javascript.
I don't need to worry about the users not having javascript because my web app requires javascript to be used anyways.
Only the most popular pages that are accessible to both logged in and logged out users will do this.
What do you guys think? Pros/cons? Is this something that websites commonly do?
Doing it for 100% of your application would be a little problematic, however, it sounds like you are seeking to use something called the Model-View-Presenter pattern:
http://en.wikipedia.org/wiki/Model_View_Presenter
Be wary that, when using javascript, your code is exposed, meaning that any security measure taken is potentially hackable through the browser. Add protection on the server side and you are set.
Also, since you are going to rely heavily on javascript, I really recommend you using Mootools, which is an object-oriented approach to javascript. That way you can keep your code really modular, work around messy implementations using custom and class events, etc.
Major con: If you are determining what content a viewer can access with JavaScript alone, it stands to reason that a malicious user can potentially access premium content with just a little glance at your source code.
I'm not sure what you are optimizing really - you need to fetch the user data anyway, and only the server has that. Do you plan on sending an AJAX request requesting for data and using javascript to format it? you are only saving on output generation which is usually not the bottleneck in web application. Much more often the database / IO (files) / network (HTTP requests) are the bottlenecks.
The major con here is that by moving all output generation to javascript, you will increase substantially the download size and reduce overall responsiveness. Since none of the big sites use this approach, you can be sure it doesn't solve scalability problems.