Google Autocomplete Referrer

[SailingSteve]

Google sees Google Places Autocomplete requests as coming from https://localhost, which means you really can't restrict access by referrer. If you used https://localhost as a referrer anyone could use your key to do google maps/places lookup and we would pay for it.

There used to be a google-plugin-googleplaces that might have solved the problem, but it is archived.

Does anyone have an idea about how to get Autocomplete working in Cordova, without allowing the world to use your billing key?

references:
https://developers.google.com/maps/documentation/places/web-service/legacy/autocomplete
https://developers.google.com/maps/documentation/javascript/reference/autocomplete-data#AutocompleteSuggestion

[breautek]

Any service that restricts their API key to a domain is not a good fit in webview apps in general (not just Cordova).

If the API key is known, anybody can make an app with any domain as the webview asset loader, and potentially use your key, not just https://localhost

Typically google APIs have a native client for android & iOS that will restrict an API key to the bundle ID on iOS, or the build key fingerprint for android. You'll need to find a plugin (or build one) that interfaces with the native mobile libraries instead of using the web API.

[GitToTheHub]

The sentence "I don't get your problem" was more related to the localhost thing, because for me it seemed, that @SailingSteve would think, that all Cordova Apps has localhost and you cannot change something on it.

I looked in Google Cloud Console what you can do about an API key restriction and the recommended way is to create a fingerpint of the release certificate of your keystore. So this is possible without a custom plugin.

[breautek]

So this is possible without a custom plugin.

No it's not. Because the JS sdks doesn't have the capability to assert the fingerprint. In order to use API keys restricted to keystore fingerprint, you have to use the android SDK. And to integrate the android SDK requires a plugin to import and to provide a cordova JS interface into the android SDK.

[SailingSteve]

https://developers.google.com/maps/api-security-best-practices

Adding the "bundle id" restriction to iOS, would be good for App Store apps, sinve the bundle id won't be forged from signed apps, but the api requests would have to come from native code. Googles API servers do not see API requests from Webviews as coming from iOS, so that did not work for me.

I haven't tried Android and the fingerprint technique, but would expect the same results.

[breautek]

It's because domain restriction is only valid for websites using the JS SDK of the service.

e.g. a domain API key restriction will apply to the Autocomplete JS api.

The android API key restriction will apply to the Autocomplete Android API
The iOS API key restriction will apply to the Autocomplete iOS API.

So if you have 3 clients, a web portal, an iOS app and an Android app. You need 3 API keys, one for each platform.

And in Cordova's case, you'd need a way to integrate the Android & iOS SDKs of the Autocomplete API, which is where the plugin is necessary.

[GitToTheHub]

I asked Gemini if it is possible to use Google Maps JavaScript API in an Android app and restrict it by a keystore certificate fingerprint with the following prompt:

Can I use Google Places JavaScript API in an Android app in a WebView and restrict access to the API key by storing the fingerprint of the certificate from the KeyStore in the Google Cloud Console?

It says:

Yes, you absolutely can use the Google Maps JavaScript API within an Android app's WebView and secure your API key by restricting access based on the SHA-1 certificate fingerprint from your Keystore in the Google Cloud Console.

Here's a breakdown of why this works and how to implement it:

Why it Works:

WebView as a Browser Environment: A WebView is essentially an embedded web browser within your Android app. When you load the Google Maps JavaScript API in a WebView, it behaves as if it's running in a standard web browser.

API Key Restrictions for Android Apps: Google Cloud Console provides a specific restriction type for API keys that allows you to limit their usage to Android applications based on their SHA-1 fingerprint of the signing certificate. This is the standard and recommended way to secure your API keys for native Android applications.

No Direct "Android API" Restriction Required: Even though you are using the JavaScript API, the WebView is operating within the context of your Android app. Google identifies your app by the certificate it's signed with.

Maybe Gemini is dreaming.

@SailingSteve You said, you tried already to restrict access on iOS by the bundle id:

Adding the "bundle id" restriction to iOS, would be good for App Store apps, sinve the bundle id won't be forged from signed apps, but the api requests would have to come from native code. Googles API servers do not see API requests from Webviews as coming from iOS, so that did not work for me.

So you activated the ios app restriction by bundle id and tried to you use the autocomplete feature? So I presume, it didn't work or did it work? Because I would presume, that it would not work, because Google sees just an api request from a webview and should block it, because it's only allowed for an ios app with a specific bundle id.

I don't know, if it is real possible to restrict the JavaScript API with the iOS-/Android app restriction but it's interesting for me if it's possible, because that would make a plugin redundant.

[breautek]

The Gemini AI is just plain wrong. The docs literally states

Note: If you place an application restriction on an API key, you cannot use it on other platforms. For example, if you restrict the API key to only Android apps, you cannot use it with iOS, web services, or JavaScript APIs.

In otherwords if you restrict to android apps, using keystore fingerprint, you cannot use that API key with JavaScript APIs. And how would it? There is no webview JS api to obtain the fingerprint of the native app build.

[GitToTheHub]

I read a little bit through the Google documentation Google Maps Platform security guidance and see, they really recommend the native SDKs to make calls, but, they also have solutions for client-side web service calls which can be made from an iOS/Android app. The solution can be:

1. Use a proxy server
2. Use HTTP Headers by using X-Android-Package and X-Android-Cert for Android and X-Ios-Bundle-Identifier for iOS.

Another side note here: Apache Cordova is related there:

Frameworks, such as Apache Cordova, allow you to conveniently create multi-platform hybrid apps running inside a webview. However, API key website restrictions are not guaranteed to work correctly, unless your web app is loaded using HTTP or HTTPS from a website that you control and have authorized.

Bundled resources, loaded locally from within a hybrid application, or accessed using a local file URL will in many cases prevent referrer based authorization from working as the browser engine powering your webview will omit sending the Referer header. To avoid this, host your web applications server-side, not client-side.

Alternatively, for mobile applications, consider using available native Google Maps Platform Android and iOS SDKs, instead of using a web based SDK.

But the documentation is old as it still mentions access using a local file URL which today is not the case anymore. So their solution is to have a server which make the api calls.

But I think too, the recommended way is to use the native SDKs.

Maybe we can ask the AI to create one :D