Why is Google API key restriction not working - api-key

I have a Google API key. It works fine. I'm seeing traffic to the Google Geocoding API using that API key:
However, I added a restriction on the API key so that this traffic to Google Geocoding API should start denying all these requests:
Doing so has had no effect. The Google Geocoding API continues to see traffic. Why is it not denying these requests? Or is it and I'll always see traffic on that graph even if it's denying the requests? The Errors graph for that same key shows no data during that time period.

You have to also select "By credential" in the 2nd dropdown. Such an annoying design!

Related

Google AI Predict API: anonymous authentication for website

After reading each of these Q&As,
google api machine learning can I use an API KEY?
how to use google AI platform online predictions?
How to authenticate GCP AI Platform Predictions using HTTP requests
I am still at a loss to know how to enable simple authentication for the AI Platform Predict API that doesn't need any sign-ins or OAuth screens.
My scenario is the following: we have a static website which allows the user to enter some data, the website (client) sends the data to the model for prediction via the API, and when the results come back, the website shows them to the user. We don't want the user to have to sign in or identify themselves in any way. Just input some data, push a button, and get the results.
However, as far as I've been able to search, there is no way of doing this (the documentation on authentication is in my view confusing, there are multiple overlapping articles and it is difficult to determine what applies in a specific case); you have to use some sort of OAuth which makes the user sign in with a Google account.
Is there really no way to have the website itself authenticated but not the individual users? E.g. using an API key or service account key?
If OAuth is the only way, does that mean users who want to use the website must have a Google Account? And how do I enable it: should I create an OAuth Client ID, or is it the OAuth consent screen?
The recommended practice here is that all the OAuth should happen server-side, where the GCP Service Account JSON key is stored on some backend server.
I am going to answer your question by assuming that your website is hosted on App Engine, but your website could be hosted any where on other GCP products as Cloud Run or any other hosting providers.
In backend webserver you can make the AI Platform predict request using Service Account JSON, then you would need to configure your website to talk to this backend.
Website ----HTTP Request to App Engine URL------> App Engine (code---)--------> AI Platform
So the App Engine backend performs the authentication on behalf of the website client, as Lak clarifies here; since the requests will be passing your GCP Service Acount JSON Key, then they gain access to send the specific HTTP requests to their backend server, which makes the AI Platform calls.
In your case, you do not want the users to access your Google data, you simply want provide them access to your own AI Platform model.
Basically you can just use Client Library on server-side and it automatically does OAuth for you, as long as environment variable is set to Service Account key.
Note: You only need to do Google OAuth IF you want access to a person's Google resources (e.g Google Doc, Calendar, GCP project, etc)

How to restrict api gateway rest api to CloudFront hosted S3 website

I have hosted a S3 static site into CloudFront. That site using rest api deployed into api gateway. API gateway has not access control.
I want to protect my api from being accessed by others. Only my static site can access it. I know I can use api key but that could expose by browser console which is not expected.
Is there other way to control my api access?
Thanks in advance
I have a similar issue as well. It seems like using referer or CORS restrictions are the best way to go. However, in practice I haven't been able to make it work after trying both CORS and referer restrictions. API Gateway has automatic protection against malicious behavior like DDOS attacks according to their FAQs, but it is disheartening that I haven't found a specific solution for protecting my API gateway that is only used for my S3/Cloudfront static site.
Google Cloud allows you to use their API keys on the frontend for integrations with services like Google Maps. The way they protect those keys is through restricting the API keys to certain domains. Unfortunately, I haven't found similar functionality for AWS keys. As you know, the only way to throttle or put quotas on API gateway is through API keys, so it looks like this would be useless for a static site that can't expose those API keys publicly on the frontend.
It defeats the whole purpose of going completely serverless if I am unable to configure my serverless API Gateway the same way I could congfigure a normal backend EC2 server. For now, I've created billing alarms so I don't get surprised with a huge AWS bill if something goes wrong with my unprotected API gateway.

API key Browser API keys cannot have referer restrictions when used with this API

I'm trying to program geocoding. I created API key, but when I add it into my website code I don't get anything, however when I don't use API everything works well. When I'm sending:
https://maps.googleapis.com/maps/api/geocode/json?address=".$adres."&key=KLUCZ_XXX
I get a response:
Browser API keys cannot have referer restrictions when used with this API.
If I use:
https://maps.googleapis.com/maps/api/geocode/json?address=".$adres"
The result is correct but the number of queries is limited per day.
Key constraint: referrals HTTP (Web) - set to the domain from which conjure inquiry. Interface Google Maps Geocoding API is turned on.
Does the API key has to be activated also somewhere else to work?
It sounds like you may be making the API call server side. I ran into this issue earlier today. Since you've placed a referrer restriction on your API key, it will be limited to executing on the browser with the web service APIs, including the Geocoding API. It didn't work for me even when manually setting the referrer in the request headers. You can find the other web service APIs on this page: https://developers.google.com/maps/web-services/
Important: If you are using any of the web service APIs with an API key that has referer restictions, your requests will fail with the error message: "API keys cannot have referer restrictions when used with this API." You should switch to using a server restriction.
You'll want to create a separate key to use server-side. You can change your restriction from a browser restriction to a server restriction by using IP addresses to restrict access, instead of browser referrers.
See this section in the Maps APIs FAQ on switching key type to a server restricted key: https://developers.google.com/maps/faq#switch-key-type
Alternatively, you can continue using a browser key and geocode client-side (JavaScript), then return the result to the backend via ajax.
If server-side geocoding is not an option, you should use the geocoder from the Google Javascript API. You can set HTTP referer restrictions on that API.
Google itself says to avoid the Non-Javascript Geocoder API for dynamic geocoding:
This service is generally designed for geocoding static
(known in advance) addresses for placement of application content on a
map; this service is not designed to respond in real time to user
input. For dynamic geocoding (for example, within a user interface
element), consult the documentation for the Maps JavaScript API client
geocoder and/or the Google Play services Location APIs.
This issue happens when you set the referrer for the server key to the domain name instead of the IP address, then it will show this message -
API keys with referer restrictions cannot be used with this API
.
For geocode API create a separate API key and restrict that API using IP address.
It worked for me.

Prevent certain referrers from using my oAuth API

According to my Google API console my top referrer is https://www.googleapis.com which I assume is normal, but it's followed closely by http://blocvox.com which I don't know what they are and I am suspicious as to why they are consuming a lot of my requests and jeopardizing my capped usage.
How can I prevent this referrer from accessing my API?
Note: I am not using an API Key (which does support the blocking of referrers) I am using the oAuth method.
The details depend on what your API is written in, but most popular Web frameworks allow you to look at the referrer value for the HTTP request. You could go further; most Web front-end servers allow you to filter/discard/reject/redirect queries based on the referrer field.

Should I trust an API that uses GET method for user auth?

I've been researching PASTEBIN type API's that would enable storage of code snippets for a project I'm working on. The problem is that most if the API's I've found do not support edit/update of existing pastes.
I found that the Snipt.org API does support snippet updates. However, authentication for the snipt.org API is done using your Twitter account. The snipt.org API docs (https://code.google.com/p/snipt-org/wiki/REST_API_Docs?tm=6#Authorization) suggest using a GET '/auth' call (providing a Twitter uname/password in the URL) to obtain an API token to access the API. Is it just me or does this seem like a good way to compromise your Twitter credentials?
I have used other sites that authenticate via Twitter, but I get authenticated on the Twitter site first which in turn sends a token to the authorized app.
Well, obviously this API has some serious flaws.
But if you use https, the URLs of GET requests will get encrypted along the way. (But still get logged in the cache of your browser. do clear it.)
So if you really like snipt, you could use a new twitter account created simply for the purpose of authenticating to snipt.
It won't feel particularly good. And I have some serious doubts about the rest of their security code based on this part of the API. But I do not see how exactly your credentials could be stolen using this part of it by others than the snipt maintainers who already have access to your snipts. So if you protect only snipts with the credentials, and no tweets, you should be alright.