YouTube API v3 key protection in client application

Question

I am looking at the following guide: https://developers.google.com/youtube/v3/getting-started

The first step in interacting with the YouTube API is:

You need a Google account to access the Google Developers Console, request an API key, and register your application.

And they continue to show an example of using a key:

URL: https://www.googleapis.com/youtube/v3/videos?id=7lCDEYXw3mM&key=YOUR_API_KEY & amp; part = snippet, contentDetails, statistics, status

I have a client application that is used by many people. The application issues searches in the YouTube API. The YouTube API has a request limit of 50 million requests per day.

Since this is a client application, my API key is embedded in the code.

Today, an attacker wrote something to maximize requests:

I wonder what kind of regression I should be able to protect from this kind of activity. Is my only option for hosting a server, routing all YouTube API requirements through my server, and rejecting requests when they appear too often?

I have a real concern for implementing something like this. This will effectively double the latency for each API request, as well as impose a seemingly extra amount on the server, but perhaps this is necessary.

Do I have any other options?

thanks

Answer 1

This was due to an increase in the cost of the quota; it was temporarily returned. We will announce cost changes in http://apiblog.youtube.com/ and https://developers.google.com/youtube/v3/revision_history in the future.

Answer 2

Do not think that this is a malicious user. I think something is wrong on the YouTube side, as I see exactly the same problem with API requests made from my application

Answer 3

You can use the restriction to protect your API key.

Use the REFERERS attribute of the REFERERS public key. Go to your project in console developers -> API&Auth -> Credentials

• If you use Key for browser applications, REFERERS is a domain link.
• If you use a server key, REFERERS is a reference to IP. (ip of your server, for example)

For example, if you use imtqy.com to demonstrate the application in real time, REFERERS will point to http://user.imtqy.com/*

You can read more to register your application.

• Use the server key if your application runs on the server. Do not use this outside of your server code. For example, do not plug it into a network page. To prevent the theft of quotas, limit your key to only allow from the source IP addresses of your servers.

• Use a browser key if your application runs on a client, for example, in a web browser. to prohibit the use of your key on unauthorized sites, allow referrals from domains that you administer.

A screen to help you:

Answer 4

This seems like a serious mistake. The same problem here is the use of quotas, similar to crazy since September 3, and requests now cost WAY more than status documentation .

Someone reported this as a defect in their bug tracking system. I suggest that everyone who is injured go there and cause a defect to draw attention to it:

• https://code.google.com/p/gdata-issues/issues/detail?id=6623&q=label%3AAPI-YouTube&sort=-id&colspec=API%20ID%20Type%20Status%20Priority%20Stars%20Summary

Answer 5

I suggest the following ideas:

• You can verify that the user accessing your page is human (with Captcha, etc.).
• Hide the API call behind the AJAX call that is launched by your interface (for example, GET / callgoogleapi);
• An AJAX call handler can set a frequency threshold, i.e. 2 requests per second. If too fast, the API call is not made, and AJAX responds to the message, for example, "User operation is too fast."

Answer 6

It is right. When you make your key, be sure to use REFERERS so that even if you have a key, it will not work for them!

Answer 7

We also see this error, it seems too big deviations. results An overview of 813.844, but 49,379,348 out of 50,000,000 requests are used by APIs today