I'm getting ready to launch an Angular/Node web application which uses the YouTube V3 API. The app was released about 3 weeks ago as a "beta version" for market validation and was pretty successful in beta. It's not going to be a commercial success, just a fun app that makes peoples lives a little bit easier. I have one issue/concern, should I be hiding my YouTube V3 API key, client id, and scopes? Or can I assume that since only my domain name is whitelisted, that the potential hackers/people who try to use the API key, won't be able to make any calls or do any damage so therefore I have nothing to worry about?
These are the specific calls I'm worried about (not the real ids/keys)
Index.html Script Tag
var OAUTH2_CLIENT_ID ='_#H#RJHWEJFHEFUIEHFUHEFHEJFU.apps.googleusercontent.com';
var OAUTH2_SCOPES = ['https://www.googleapis.com/auth/youtube'];
In Angular, Controller.js
.value('google_api_key', 'jfasdkjfdnstnewurweqjtndi')
gapi.client.setApiKey(google_api_key);
For Simple Access to Google APIs, API key is the only credential required for the request, and it is a unique identifier of your app/project. It provides API access and is subject to quotas.
You should keep it a secret!
If you have a client-side-only app (without a server), then use OAuth 2.0 Client-side Flow
From Google's Documentation:
Best practices for securely using API keys:
When you use API keys in your applications, take care to keep them secure. Publicly exposing your credentials can result in your account being compromised, which could lead to unexpected charges on your account. To keep your API keys secure, follow these best practices:
Do not embed API keys directly in code
API keys that are embedded in code can be accidentally exposed to the public—for example, if you forget to remove the keys from code that you share. Instead of embedding your API keys in your applications, store them in environment variables or in files outside of your application's source tree.
Do not store API keys in files inside your application's source tree
If you store API keys in files, keep the files outside your application's source tree to help ensure your keys do not end up in your source code control system. This is particularly important if you use a public source code management system such as GitHub.
Restrict your API keys to be used by only the IP addresses, referrer URLs, and mobile apps that need them
By restricting the IP addresses, referrer URLs, and mobile apps that can use each key, you can reduce the impact of a compromised API key. You can specify the hosts and apps that can use each key from the Google Developers Console by opening the Credentials page and then either creating a new API key with the settings you want, or editing the settings of an API key.
Delete unneeded API keys
To minimize your exposure to attack, delete any API keys that you no longer need.
Regenerate your API keys periodically
You can regenerate API keys from the Google Developers Console by opening the Credentials page and clicking Regenerate key for each key. Then, update your applications to use the newly-generated keys. Your old keys will continue to work for 24 hours after you generate replacement keys.
Review your code before publicly releasing it
Ensure that your code does not contain API keys or any other private information before you make your code publicly available.
Related
I can login with
<script src="https://accounts.google.com/gsi/client" async defer></script>
I have created an api key for google drive on the console dashboard. According to Drive js api. I should not put the key in a public webpage.
Is there a way to get my api key from after logging in with the account that owns the key via javascript?
An api key is used for accessing public apis. Unless the file you are trying to access is public you are not going to be able to access it. That tutorial also tells you to create Web application. Which will allow you to authorize your user to access their data.
Is there a way to get my api key from after logging in with the account that owns the key via javascript?
Api keys and web application credentials as which that tutorial shows you how to create are owned by you the developer. They are used to request authorization of the users of your application. So no there is no way that the users of your application could give you an api key that must be created by you the developer.
Restrict your api key
due to the fact that javascript is client side if anyone does a view source they are going to see your api key. That is why it is a good idea to setup restriction for your key in Google clound colsone
Apikeys
There are a number of ways to restrict your key
You can restrict it by API restrictions limiting what apis it can be used for.
You can set up Application restrictions which will limit things like what websites it can be used from or an ip address.
A key in production should always have restrictions applied.
I have a simple interface but I work with multiple APIs so I don't want to use a backend for it. How can I hide my API keys in CRA without using backend.
It is suggested to use environment variables for this and I have also used it as shown in the documentation but this is not exactly what I want. Even though I use environment variables , a simple CTRL + F search in the "chunk.js" files reveals things that should remain hidden, like my API keys. Is there a way to completely prevent this?
No, not really, and otherwise they could sniff them out with wireshark easily enough or other network monitoring tools.
The way to combat this is making your own api that connects with the other api's, that returns the required content.
Then they need to obtain a license key for your api, that you can revoke from your server as valid if you wish to refuse access to a publicly traded license key to your api.
If you wanna use any API key in JS bundle like this it will be bundled, either you bundle it or you don't.
So you can:
Bundle API key with JS(not secure)
Get API key via API endpoint
Can obfuscate key in client bundle https://github.com/anseki/gnirts , but it's still not secure and somebody can figure it out eventually.
OBJECTIVE
I want to retrieve JSON(P) data from tools I use (Quickbooks, Zoho, etc.) for custom reporting in Google Spreadsheets. Object Parameters (e.g "Account.name", "Account.birthday") would be listed across Row 1 in Spreadsheets and data would be dumped into the columns.
I know I can run javascript scripts in Google Spreadsheets via their script editor and I know some javascript - at least enough for array and object manipulation (not familiar with APIs)...
QUESTION
I think I can make JSONP requests for x-domain API requests (via
HTTPS) - am I correct?
For private APIs, I'll have to pass in an Private API Token - can I
prompt a user to insert their API key and then make a request? As a
result, no API keys will be stored permanently. Is this okay?
I'm pretty sure I've seen some websites that have API keys in their URL (soundcloud?) - I thought that having visible API keys is dangerous (someone can steal your key and abuse the company's servers). Am I wrong in my thinking?
Once again, I am fairly new to programming so feedback (and reading resources) would be greatly appreciated!
I'm having some issues understanding the differences between an API Key and a Developer's Key when it comes to utilizing the YouTube API.
My application is using the restful requests in v3 of the Youtube API and I can set an API key via the gapi.client.setApiKey() function , which I have done during development, but when I was looking at the quotas, https://groups.google.com/forum/?fromgroups=#!topic/youtube-api-gdata/e1JDQ4lqbXU, it states that they are tied to a developer key instead and that the developer key should be sent with each request. I went ahead and got one for development purposes, but I'm not sure how they interact with each other.
I also didn't find any details on how to send the developer's key with each restful request (such as gapi.client.youtube.channels.list), only how to include it in the header or query string when making a regular get request.
Can someone help me understand the difference between the two, how they are related, whether I need both, and how to use them in restful requests, or if I need to switch to regular get requests?
Sorry for the confusion.
"Developer keys" refer to keys that worked with v1 or v2 of the YouTube Data API. You can obtain them here. There's a separate quota system in place for v1/v2 and yes, developer keys do come into play there.
"API Keys" refer to keys that you use when making unauthenticated requests using v3 of the YouTube Data API. (If you're making an authenticated request, you don't include an API Key, since the OAuth 2 client id/secret identifies your application.) You get an API Key that you could use with YouTube from the Google APIs console, after turning on the YouTUbe Data API v3 as one of the Services you're using. Quota in v3 is tied to your API Console project, and your API Key identifies which project you're using.
The takeaway is that if you're making unauthenticated YouTube Data API v3 calls, you should only include an API Key from the Google APIs console in your request. If you're using the JavaClient library, that's done via gapi.client.setApiKey().
I am about to publish a demo JavaScript application based on eBay finding API on my personal website; I was wondering if there is a way to prevent my AppID from being read and exploited.
Is it possible to associate the AppID to a specific domain ? I haven't been able to find an answer neither on eBay Developer Forums nor in the official documentation.
If you send data to the client, the client can read the data. There is no way to prevent this (if JavaScript can decode it, so can the user). In order to avoid that, you need to keep the data (your AppID) on your site, and process the request on your server. So the JavaScript needs to talk to your server, and your server will then pass on the request to eBay, adding the AppID, and then pass the results back to the JavaScript.
To answer your question...
It doesn't seem possible to restrict AppIDs as the limits don't work on a per-site basis like that and you usually have just one AppID for all your uses/sites. See this comprehensive thread from 2010 (quoted below), I doubt much has changed. The end result is it basically doesn't matter for a read-only application such as search results on your website.
More generally about securing JSON API calls in-browser
Checking the referrer is the best way to secure an otherwise public API. This is how Google restricts their API keys for maps, for instance: https://developers.google.com/maps/documentation/javascript/tutorial
About the only thing that will prevent fraud is activity monitoring, given that the API is called from third-party computers, one would have to track trends for abuse, perhaps by comparing a list of calls to other website activity, or by using JSONP to inspect the browser's properties with AJAX. Google can cross-reference their API calls with their Google Analytics calls, for example, though there could always be false positives.
In the end, if the fear is CSRF, there's this: How to reliably secure public JSONP requests?
Quoting verbatim from the eBay thread in case the URL changes again:
There is one DevID per developer account.
There could be multiple AppID, but these are only available via paid support ticket.
Each AppID can have multiple CertID. The CertID determines your call limits.
You can generate unlimited tokens for each AppID. Each token is a pairing of AppID, UserID, and the associated eBay user's password. Tokens are currently active for 18 months. They must then be regenerated. Tokens can also be prematurely 'revoked' either via the API or website preferemces.
For the API families that require a token, you can use a single token based on your own UserID to retrieve most public information. However, private transaction details are only available when you use a token generated for the target UserID. Some calls actually derive the UserID from the token.
If multiple applications share the same AppID, they will both contribute towards the daily call limits. That's why you might want to request a separate AppID.
https://www.x.com/developers/ebay/ebay-api-call-limits
The limits shown in the chart are 'aggregate' for the given API family. There's an implicit per-AppID. For the Trading API, eBay further limits use on a per-call or per-time-interval basis. Some calls like AddItem have higher limits. GetApiAccessRules will return your actual limits and usage.
Per-IP-address means the IP address of the calling machine. If you were to rotate through multiple IP addresses, you'd actually multiply your limit. There are many read-only 'widgets' written in JavaScript or Flash which run in the client browser and thus use the client IP to make the calls. In that case, the call limit is pretty insignificant.
AppID, DevID and CertID belong to the creator of the developer account. That creator is bound by the API license provisions.
As the owner of the keys, you are not to allow any 3rd-party programmatic control of the API. Strictly speaking, that means that both the keys and any token derived from those keys should remain private (i.e. under your exclusive control).
Obviously, eBay does not enforce that strict interpretation since FetchToken is suggested for client-side applications. A sophisticated user could easily grab the token coming or going. What harm can someone do with a token based on their own UserID?
Burn through your daily call limit
Create an API application that violates the license
For more of the debate, see this earlier thread. (Link broken)
Once your application passes the eBay Compatible Application Check, you can request either 1.5M shared or 20K calls per user.
For further information about eBay's APIs, I suggest asking on their forum.