Google Maps Platform security guidance

  • Secure your Google Maps Platform API keys by restricting their usage to specific applications and APIs.

  • Safeguard your API keys by storing them securely outside your application's source code, never exposing them directly in client-side code.

  • Implement App Check to enhance security by verifying the legitimacy of app requests and blocking unauthorized API calls.

  • Use separate API keys for each application to minimize the impact of a compromised key and better manage usage quotas.

  • Regenerate API keys cautiously and only as a last resort, understanding the potential implications and disruptions it may cause to your applications.

Apps and projects that use the Google Maps Platform APIs and SDKsmust useAPI keys or, if supported, OAuth 2.0, to authenticate themselves.

These best practices show you how to secure yourMaps Platform access.

If you want to use OAuth 2.0 to authorizeserver-to-server traffic,look for the OAuth topic in your API documentation.SeeUse OAuth for server-side apps for moredetails.

Important: Restrict you API keys to prevent unauthorized usage. You are financially responsible for charges caused by abuse of unrestricted API keys.

In addition to applying application and API key restrictions, follow anysecurity practices that apply to specific Google Maps Platform products. Forexample, see the Maps JavaScript API below inRecommendedapplication and API restrictions.

If your API keys are already in use, review the recommendations below inIf youare restricting an API key that's in use.

For more details about digital signatures, supported byMaps Static API and Street View Static API, see theDigital Signature Guide.

Recommended best practices

For increased security and to avoid being billed for unauthorized use, followthese API security best practices for all Google Maps Platform APIs, SDKs, orservices:

Recommended for all API key uses

Restrict your API keys

Use separate API keys for each app

Delete unused API keys

Check your API key usage

Be careful when rotating API keys

Split client-side and server-side usage into separate projects

Disable unused services

Additional recommendations for client-side apps

Use client-side SDKs

Secure client-side web service calls

Additional recommendations for websites or client-side apps using Static Web APIs

Protect Static Web API usage

Additional recommendations for server-side apps using web services

Protect web service API keys

Use OAuth for server-side apps

If you are restricting or rotating an API key that's in use

  • Before you change the API key,Check your API key usageThis step is especially important if you are adding restrictions for akey that is already in use in a production application.

  • After you change the key, update all of your apps with the new API keys, asneeded.

  • If your API key has not been compromised and is not actively abused,you can migrate your apps to multiple new API keys at your own pace, leavingthe original API key untouched until you only observe one type of traffic,and the API key can safely be restricted with a single type of applicationrestrictions without causing unintended service disruptions.

    For further instructions, seeMigrate to multiple API keys.

    Monitor the usage over time, and see when specific APIs, platform types, anddomains have migrated off the old API key before you choose to restrict ordelete the old key. For more information, seeReporting andmonitoring andMetrics

  • If your API key has been compromised, you want to move more quickly tosecure your API key and stop the abuse. In Android and iOS apps, keys aren'treplaced until customers update their apps. Updating or replacing keys inon webpages or in server-side apps is much more straightforward, but maystill require careful planning and fast work.

    For more information, seeHandle unauthorized use of an API key.

More information

Recommended application and API restrictions

Restrict your API keys

Tip: If you are restricting an API key that's already in use, also see sectionIf you are restricting or rotating an API key that's in use.

Best practice is to always restrict your API keys with one type of applicationrestrictions and one or more API restrictions. For suggested restrictions by API,SDK, or JavaScript service, seeRecommended application and APIrestrictions below.

Set an application restriction for an API key

  1. Open the Google Cloud consoleGoogle Maps Platform Credentials page.

  2. Select the API key that you want to restrict.

  3. On theEdit API key page, underKey restrictions, selectSet an application restriction.

    Edit API key page

  4. Select one of the restriction types and supply the requested informationfollowing the restriction list.

    Restriction typeDescription
    WebsitesSpecify one or more referrer websites.
    • The universally supported referrer URI schemes arehttps andhttp. Other schemes are not guaranteed to work correctly, since modern web browsers will for privacy reasons not send a `Referer` header in outgoing requests.
    • Always provide thewhole referrer string, including the protocol scheme, hostname and optional port (e.g.,https://google.com).
    • You can use wildcard characters to authorize all subdomains. For example,https://*.google.com accepts all sites ending in.google.com.
    • Be careful when authorizing full-path referrers, for example,https://google.com/some/path, since most web browsers will for privacy reasons strip the path from cross-origin requests.
    IP addressesSpecify one or more IPv4 or IPv6 addresses, or subnets using CIDR notation. The IP addresses must match the source address the Google Maps Platform servers observe. If you usenetwork address translation (NAT), this address typically corresponds to your machine'spublic IP address.
    Android apps

    Add the Android package name (from theAndroidManifest.xml file) and the SHA-1 signing certificate fingerprint of each Android application you want to authorize.

    1. SelectAndroid apps.
    2. Click+ Add.
    3. Enter your package name and SHA-1 certificate fingerprint. For example:
      com.example.android.mapexample
      BB:0D:AC:74:D3:21:E1:43:67:71:9B:62:91:AF:A1:66:6E:44:5D:75
    4. ClickSave.

    There are two certificate types:

    • Debug certificate: Only use this certificate type with apps you're testing and other non-production code. Don't attempt to publish an app that's signed with a debug certificate. The Android SDK tools generate this certificate automatically when you run a debug build.
    • Release certificate: Use this certificate when you're ready to release your app to an app store. The Android SDK tools generate this certificate when you run a release build.

    For more information about Android application signing and certificates, see theSign your app guide.

    If you usePlay App Signing, to fetch the signing certificate fingerprint, seeWorking with API Providers. If you manage your own signing key, seeSelf-signing your application or refer to the instructions for your build environment.

    iOS apps

    Add thebundle identifier of each iOS application you want to authorize.

    1. SelectiOS apps.
    2. Click+ Add.
    3. Add the bundle ID to accept requests from the iOS app with that ID.
    4. ClickSave.

    For recommendations for an application restriction, seeRecommendedapplication Restriction.

  5. SelectSave.

Set API restrictions for an API key

  1. Open the Google Cloud consoleGoogle Maps Platform Credentials page.

  2. Select the API key that you want to restrict.

  3. On theEdit API key page, underAPI restrictions:

    • SelectRestrict key.

    • OpenSelect APIs and select the APIs or SDKs you want yourapplication to access using the API key.

    If an API or SDK is not listed, you need to enable it. For details, seeToenable one or more APIs or SDKs.

    Restrict an API on the Edit API key page

  4. SelectSave.

    The restriction becomes part of the API key definition after this step. Besure you provide the appropriate details and selectSave to save yourAPI key restrictions. For further information, see theGet an API Key guide in the documentation for the specific API or SDKyou are interested in.

For recommended API restrictions, seeRecommended APIRestrictions.

Check your API key usage

If you're restricting API keys after they've been created, or if you want to seewhat APIs are being used by a key so you can restrict them, you want to checkyour API key usage. These steps show you in which services and API methods anAPI key is being used. If you see any usage beyond Google Maps Platformservices, investigate to determine if you need to add more restrictions to avoidunwanted use. You can use the Google Maps Platform Cloud Console Metricsexplorer to help determine which API and application restrictions to apply toyour API key:

Tip: If you don't see all chart labels when you open the Metrics explorer, seethese topics in the Google Maps Platform Cloud Console Metrics explorer help:Toggling the chart's fulllegends andShow all legendcolumns.

Determine the APIs that use your API key

The following metrics reports allow you to determine which APIs are using yourAPI keys. Use these reports to do the following:

  • See how your API keys are used
  • Spot unexpected usage
  • Help verify if an unused key is safe to delete. For information aboutdeleting an API key, seeDelete unused API keys.

When applying API restrictions, use these reports to create a list of APIs toauthorize, or to validate automatically-generated API key restrictionrecommendations. For more information about recommended restrictions, seeApplyrecommended restrictions. For more information about using theMetrics explorer, seeCreate charts with Metricsexplorer .

  1. Go to the Google Cloud console'sMetricsexplorer

  2. Sign in and select the project for the API keys you want to check.

  3. Go to the Metrics explorer page for your type of API:

  4. Inspect each API key:

    1. SelectADD FILTER.

    2. Select thelabelcredential_id.

    3. Select thevalue corresponding to the key you want to inspect.

    4. Note which APIs this API key is being used for, and confirm the use isexpected.

    5. Once done, selectRemove filter at the end of the active filterline to delete the extra filter.

  5. Repeat for any remaining keys.

  6. Restrict your API keys to only the APIs that are being used.

  7. If you spot unauthorized use, seeHandle unauthorized use of an APIkey.

Choose the correct type of application restriction using the Metrics explorer

After you have verified and taken any needed actions to make sure your API key isonly used for the Google Maps Platform services it is using, also verify theAPI key has the correct application restrictions.

If your API key has recommended API key restrictions, apply them. For moreinformation, seeApply recommended API key restrictions.

If your API key doesn't have restriction recommendations, determine the type ofapplication restriction to apply, based on the reportedplatform_type usingthe Metrics explorer:

  1. Go to the Google Cloud console'sMetricsexplorer

  2. Sign in and select the project for the APIs you want to check.

  3. Go to this Metrics explorer page:Metricsexplorer.

  4. Inspect each API key:

    1. SelectADD FILTER.

    2. Select thelabelcredential_id.

    3. Select thevalue corresponding to the key you want to inspect.

    4. Once done, selectRemove filter at the end of the active filterline to delete the extra filter.

  5. Repeat for any remaining keys.

  6. Once you have the platform type for your API keys, apply the applicationrestriction for thatplatform_type:

    PLATFORM_TYPE_JS : Apply Website restrictions on the key.

    PLATFORM_TYPE_ANDROID : Apply Android application restrictions on the key.

    PLATFORM_TYPE_IOS : Apply iOS application restrictions on the key.

    PLATFORM_TYPE_WEBSERVICE : Youmay have to rely on IP addressrestrictions on the key, to properly restrict it.

    For recommendations for Maps Static API andStreet View Static API, seeProtect Static Web API usage.

    For Maps Embed API recommendations, seeWebsites with the Maps Embed API.

    My API key is using multiple platform types:Your traffic can't be properly secured with just a single API key. You needto migrate to multiple API keys. For more information, seeMigrate to multiple API keys.

Use separate API keys for each app

This practice limits the scope of each key. If one API key is compromised, youcan delete or rotate the impacted key without needing to update your other APIkeys. You can create up to 300 API keys per project. For more information, seeLimits on APIkeys.

While one API key per application is ideal for security purposes, you can userestricted keys on multiple apps as long as they use the same type ofapplication restriction.

Apply recommended API key restrictions

Tip: To receive important updates about these automated API key restrictionrecommendations, star the public issue286524779.

For some project owners, editors and API key administrators, theGoogle Cloud console suggests specific API key restrictions to unrestricted APIkeys based on their Google Maps Platform usage and activity.

Caution: If also use your API key on services other than Google Maps Platform (such as Cloud), you should only apply restrictions after a thoroughmanual review.

If available, recommendations appear as pre-filled options on theGoogle Maps Platform Credentials page.

Important: The list of recommendationsmay be incomplete. Make sure to double-check your API key usage following the Google Cloud console instructions, andCheck your API key usagebefore you apply the recommendations.

Google Maps Platform APIs and SDKs supported by the automated recommendations

  • Maps JavaScript API, includingDirections Service (Legacy),Distance Matrix Service (Legacy),Elevation Service,Geocoding ServicePlace class,Place Autocomplete Widget (New),Place Autocomplete Data API,Places Library,Places Service,Place Autocomplete Widget, andPlaces UI Kit

  • Maps Static API and Street View Static API

  • Maps Embed API

  • Maps SDK for Android, Navigation SDK for Android,Places SDK for Android, and Places UI Kit on Android

  • Maps SDK for iOS, Navigation SDK for iOS,Places SDK for iOS, Places Swift SDK for iOS, andPlaces UI Kit on iOS.

Reasons you maynot see a recommendation, or an incomplete one

Reasons for seeing no recommendation

  • You are (also) using the API key on other than Google Maps Platformservices, or or Maps Platform services that arenot yet supported bythe automatic recommendations.

    If you see usage on other services,don't apply therecommendation withoutfirst doing the following:

    1. Verify that the API usage you see in the Google Cloud console Metricsexplorer is legitimate.

    2. Manuallyadd missing services to the list of APIs to be authorized.

    3. Manuallyadd any missing application restrictions for the servicesadded to the API list. If your other added would require a differenttype of application restrictions, seeMigrate to multiple APIkeys.

  • Your API key is not used in client-side SDKs or APIs.

  • You use the API key in a low-volume app or website that has not seen usageover the last 60 days.

  • You have created a new key very recently, or you have very recently deployedan existing key in a new app. If this is the case, just wait a few more daysto allow the recommendations to update.

  • You are using the API key in multiple applications that would requireconflicting types of application restrictions,or you are using the sameAPI key in too many different apps or websites. In either case, as a bestpractice, you should migrate to multiple keys. For more details, seeMigrate to multiple API keys.

Reasons for seeing an incomplete recommendation

  • You use the API key in a low-volume app or website that has not seen usageover the last 60 days.

  • You havevery recently started using a existing key on a new API orservice, and the automatic API key restriction recommendation pipeline, hasnot yet processed the updated usage metrics. The propagation of usagemetrics may take a few days.

    If you see usage on other services,don't apply therecommendation withoutfirst doing the following:

    1. Verify that the API usage you see in the Google Cloud console Metricsexplorer is legitimate.

    2. Manuallyadd missing services to the list of APIs to be authorized.

    3. Manuallyadd any missing application restrictions for the servicesadded to the API list. If your other added would require a differenttype of application restrictions, seeMigrate to multiple APIkeys.

    4. Unless youurgently need to restrict a key, for example, due tounauthorized use, youmight also wait a day or two for therecommendations to catch up.

      Tip: In an emergency, seeHandle unauthorized use of an API key.

Reasons you might see recommendations that arenot visible in the charts

  • Your app or website sent only very short traffic bursts. In this case,switch from aCHART view to display aTABLE orBOTH, as theusage is still visible in the legend. For more information, seeTogglingthe chart's fulllegends.

  • Your traffic is from the Maps Embed API. For instructions, seeDetermine the APIs that use your API key.

  • The traffic from the app or website is outside the date range available inthe Google Cloud console Metrics explorer.

To apply recommended restrictions

  1. Open the Google Cloud consoleGoogle Maps Platform Credentials page.

  2. If available, selectApply recommended restrictions.

    Apply recommended restrictions

    Note: If you don't see any recommended restrictions, seeSet API restrictions for an API key to set appropriate restrictions.

  3. SelectCheck API usage to verify which services the API key is beingused on. If you see other than Google Maps Platform services,pauseto manually review the recommendation steps above. See the troubleshootingsteps at the beginning of sectionApply recommended API key restrictions.

  4. Double-check that the pre-filled restrictions match the websites and appswhere you expect to use your API key.

    Best Practice: Document and remove any application or API restrictionsthat are not affiliated with your services. If something breaks due to anunexpected dependency, then you can add the required apps or APIs back in.

    • If you recognize that an app, website or API is clearly missing fromyour recommendation, add it manually or wait a couple of days to allowthe recommendation to update.

    • If you need further help with your suggested recommendation,contactsupport.

  5. SelectApply.

What to do if your application gets rejected after applying a recommendation

If you notice that an app or website gets rejected after applying a restriction,look for the application restriction you need to add in the API response errormessage.

Client-side SDKs and APIs

Browser and webview based apps
Caution: Exotic referrer URI schemes (i.e., not HTTPS or HTTP) arenot well supported, and should be avoided if possible. Unless noted otherwise, don't expect Google Maps Platform service or APIs to support other referrer URI schemes that HTTPS or HTTP.

Modern browsers typically redact theReferer header in cross-originrequest for privacy reasons, often stripping it down to theOrigin.However, the exact behavior depends on the appliedreferrer-policy of thehosting site, and may also vary, based on the user browser and version.

Web applications using opaque or local URI schemes for loading content willtypically have the rendering browser or webview completely redact theReferer header from any outgoing calls, which may cause requests to failusing API keys with website restrictions.

For further guidance, seeHost your browser based apps on a server.

Troubleshooting instructions for browser and webview based apps:

  • For Maps JavaScript API, see the browser debug console fordetails on how to authorize your application.

    Exotic URI schemes arepartially supported. If parts of yourapplication don't work it an exotic URI scheme, even after authorizingthe required referrer, you will likely need to host your applicationremotely on a server and load it over HTTPS (or HTTP).

    If you need help with exotic URI schemes,contact support.

  • Other Maps Platform APIs will generally return thereferrer you need to authorize in the API error response, presuming theclient sent this information with the rejected request.

    Exotic URI schemes arenot supported.

Android apps

UseAndroid Debug Bridge (adb) orLogcat

iOS apps

SeeViewing Log Messages

Apps calling web services directly

For applications calling Maps Platform HTTPS REST API orgRPC endpoints directly without a client-side Google Maps Platform SDK, seebelow:

Android and iOS apps

If your Android or iOS application calls Maps Platformservices directly without using any of the availableGoogle Maps Platform client SDKs, seeAndroid apps andiOS apps for further troubleshooting tips,andSecure client-side web service callsfor current best security practices for mobile use cases.

If your app logs Maps Platform API error responses, theabove instructions for client-side SDKs may also prove useful fortroubleshooting authentication issues.

Server-side apps

Server-side applications relying on API keys are bestsecured through IP address restrictions. If you have applied IP addressrestrictions to your key, and your service logsMaps Platform API error responses, check your systemlogs for further information. The error response will include the serverIP address that you need to authorize.

Browser or webview based apps

While Maps Static API, Street View Static API morerecent Google Maps Platform APIs will also support referrerrestrictions, note that web browsers or webviews will likely restrict theReferer header to theOrigin for cross-origin requests, and willlikely omiy sending it altogether, e.g., for locally accessed resources, orfor resources served over protocols other than HTTP or HTTPS.

If you can't use Maps JavaScript API in your application,and website restrictions don't work,seeSecure client-side web service callsfor how to issue Maps Platform web service callssecurely from within your browser based client-side application.

Tips for checking API restrictions

To check your required API restrictions, seeDetermine the APIs that use yourAPI key.

If you are unable to determine which restrictions to apply:

  1. Document the current restrictions for future reference.
  2. Remove them temporarily while you investigate the issue. You can check yourusage over time using the steps inCheck your API keyusage.
  3. If needed,contact support.

Delete unused API keys

Important:Check your API key usage before deleting it.

Before you delete an API key, make sure that it is not used in production. Ifthere is no successful traffic, the key is likely safe to delete. For moreinformation, seeCheck your API key usage.

To delete an API key:

  1. Open the Google Cloud consoleGoogle Maps Platform Credentials page.

  2. Select the API key you want to delete.

  3. Select theDelete button near the top of the page.

  4. On theDelete credential page, selectDelete.

    Deleting an API key takes a few minutes to propagate. After propagationcompletes, any traffic using the deleted API key is rejected.

Important: If you have deleted a key that is still used in production and need to recover it, seeUndelete an API key.

Be careful when rotating API keys

Important:Check your API key usage before rotating it.

Rotating an API key creates a new key that has all the old key's restrictions.During this time window, both the old and new key are accepted, giving you achance to migrate your apps to use the new key.

Before rotating an API key:

  • First try to restrict your API keys as described inRestrict your APIkeys.

  • If restricting your API key is not possible due to conflicting applicationrestriction types, migrate to multiple new (restricted) keys as described inMigrate to multiple API keys. Migratinglets you control the migration and roll out timeline to the new API keys.

If the preceding suggestions aren't possible, and you must rotate your APIkey to prevent unauthorized use, then follow these steps:

  1. Open the Google Cloud consoleGoogle Maps Platform Credentials page.

  2. Open the API key you want to rotate.

  3. At the top of the page, selectRotate key.

  4. Optionally, change the API key name.

  5. SelectCreate.

  6. Update your applications to use the new key.

After you have updated your applications to using the new key, delete the oldkey by clicking theDelete the previous key button under the Previous Keysection of the new API key page.

Important:Check your API key usage before deleting your old key, to verify that you have migrated all your applications.

Migrate to multiple API keys

To migrate from using one API key for multiple apps to a single unique API keyfor each app, do the following:

  1. Identify which apps need new keys:

    • Web apps are the easiest to update, since you control all of the code.Plan to update all of your web-based apps' keys.
    • Mobile apps are much harder, since your customers must update their appsbefore the new keys can be used.

  2. Create and restrict the new keys: Add both an application restrictionand at least one API restriction. For more information, seeRecommendedbest practices.

  3. Add the new keys to your apps: For mobile apps, this process may takemonths until all of your users update to the latest app with the new APIkey.

Important: While you can secure API keys after they're created and in use, in mobile apps (Android and iOS), keys aren't replaced until customers update their apps. Updating or replacing keys in JavaScript or web service apps are much more straightforward, but it still may require careful planning and fast work. For more information, seeIf you are restricting or regenerating an API key that's in use.

Split client-side and server-side usage into separate projects

If you need to call Google Maps Platform services both from server-sideapplications and directly from client-side applications running end-userdevices, Google recommends splitting up your usage between two separate projects.

This approach lets you apply appropriate per-minute, per-user quota limits onmost Google Maps Platform services on your client-side project, helpingto make sure all end users get their fair share of your overall project quotawithout impacting each other.

However, since per-user quota restrictions impact both client-side andserver-side applications, if you also require high bandwidth for yourserver-side jobs, set up a separate project for this use case, configuredwith a higher per-user quota limit, or no limit at all.

Disable unused services

Don't leave unused services enabled on a project, as this practice isvulnerable to abuse,especially if you have not restricted all your publicAPI keys. As a best practice, only enable a service on a project once it isneeded by your applications.

Adding API restrictions on a key prevent its use on services that it hasn't beenauthorized for, but API restrictions only apply to that specific key. Disable aservice at the project level to prevents unauthorized use of the service onany key linked to the project.

Use client-side SDKs

When using provided client-side Google Maps Platform SDKs, you will always beable to apply proper restrictions to your API key to secure your service usage.

Using client-side SDKs will also allow you to adopt more advanced securitymechanism, such as Firebase App Check on the Maps PlatformAPI surfaces that support it. SeeUse App Check to secure your API keyfor further details.

If client-side SDKs are not available for your platform, seeSecure your client-side web service calls.

For the availability of client-side Google Maps Platform SDKs for differentplatforms, seeRecommended application and API restrictions.

Protect Static Web API usage

Important: Apply both website and API restrictions to a Static Web API key, if the key is publicly exposed on your web page, for example, inside an HTML<img> tag used for displaying a static map or Street View panorama.

Static Web APIs, such as the Maps Static API andStreet View Static API, are similar to web service API calls.

You call both using an HTTPS REST API, and you typically generate the APIrequest URL on the server. However, instead of returning a JSON response, StaticWeb APIs generate an image that you can embed in generated HTML code. Moreimportantly, it is generally the end-userclient, not the server, that callsthe Google Maps Platform service.

Tip: For more information about securing your Static Web APIs, see the blog post,Securing API keys when using Static Maps and Street ViewAPIs.

Use a digital signature

As a best practice, always use digital signatures in addition to an API key.Also, review how many unsigned requests you want to allow per day andadjustyour unsigned request quotas accordingly.

For more details about digital signatures, see theDigital SignatureGuide.

Protect your signing secret

Important: Always sign your requestsserver-side, not on the client. If you for example, do the signing client-side in JavaScript, you expose it to anyone visiting your site.

To protect Static Web APIs, don't embed your API signing secrets directly incode or in the source tree, or expose them in client-side applications. Followthese best practices for protecting your signing secrets:

Protect web service API keys

Warning: Web service API keys arenot expected to be publicly exposed to unauthorized users or untrusted applications or devices! The keys are meant to remain a shared secret between the developer's servers and Google.

For secure use of Google Maps Platform APIs and services from client-side apps, seeUse client-side SDKs andSecure client-side web service calls.

Store API keys outside of your application's source code or source tree.If you put your API keys or any other information in environment variables orinclude files that are stored separately and then share your code, the API keysare not included in the shared files. This isparticularly important if youuse a public source code management system, such as GitHub.

To help shield your web service API key against accidental use, Googlerecommends applyingAPI restrictions to any key used forMaps Platform. Furthermore, also applyingIP addressrestrictions to your web service key will protect it against help protect itagainst unauthorized use from other source IP addresses, even if the keyaccidentally leaks.

Use OAuth for server-side apps

OAuth 2.0 is an open standard for access delegation.

Warning: Even if a Maps Platform API might support OAuth,never expose service account keys in a client-side application that may be run by untrusted end users or on untrusted end user devices.

While the OAuth 2.0 protocol supports use cases, where an end user authorizes anapplication to access personal data on their behalf, the intended use case forOAuth 2.0 with Maps Platform is for the developer to utilizetemporary access tokens for authorizing their application to call an API onbehalf of their Google Cloud projectservice account with the permissions of theservice account.

As a service account may have extremely broad permissions, OAuth 2.0 isrecommended for authorizingserver-to-server calls between a developer'strusted server-side applications and Google's Maps Platformservers.

For client-side applications running on end user devices, other authenticationmethods, such as API keys, are recommended.

If you want to use OAuth 2.0 to authorize server-to-server traffic,look for the OAuth topic in your API documentation.

For example, here is the OAuthtopic for theAddress Validation API.

Secure client-side web service calls

Important: If a client-side SDK is available for a Maps Platform service on your platform, use it instead! SeeUse client-side SDKs.

If client-side SDKs arenot available, see the recommendations below.

Use a proxy server

Using a secure proxy server provides a solid source for interacting with aGoogle Maps Platform web service endpoint from a client-side applicationwithout exposing your API key, signing secret or Google Cloud serviceaccount to unauthorized users.

Tip: For Maps Static API and Street View Static API it is enough for your server to just generate the signed request URL. If the request signing logic is implemented in a proxy server, it can just issue a HTTP redirect to the client using the newly signed request URL.
This approach can, e.g., be used together with a mobile application that uses the static web APIs.

Key points:

  • Construct your Google Maps Platform requests on the proxy server.Don't allow clients to relay arbitrary API calls using the proxy.

  • Post-process the Google Maps Platform responses on your proxy server.Filter out data that the client doesn't need.

Important: Always require authentication for client access to the proxy servers.

For more information about using a proxy server, seeLiving Vicariously: Using Proxy Servers with the Google Data API Client Libraries.

Secure direct mobile web service calls

Important: Use a separate API key for your client-side web service calls, and store it in a secure keystore! This step makes it harder to scrape API keys and other private data directly from the application.

If you are unable to set up asecure proxy server for yourclient-side app, secure your application using the following steps:

  1. Use HTTP headers:

    • Android: Use theX-Android-Package andX-Android-Cert HTTP headers.

    • iOS: Use theX-Ios-Bundle-Identifier HTTP header.

  2. Add the corresponding application restrictions to your Android or iOS key.

    Important: Android and iOS application restrictions may not be fullysupported on older legacy Google Maps Platform services.

  3. Before you consider issuing calls directly from your mobile application toa Google Maps Platform REST API web service, verify that requests withincorrect Android or iOS application identifiers are rejected.

    If Android and iOS application restrictions are not supported on the testedendpoint, Googlestrongly recommends that you use asecure proxy server between your mobile clients and theGoogle Maps Platform web service endpoint.

Tips for Android applications:

Tips for iOS applications:

For further information, refer to articlesManage API keys andUse API keys to access APIs.

Host your browser based apps on a server

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

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

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

Use App Check to secure your API key

Certain Maps SDKs and APIs allow you to integrate withFirebase AppCheck. App Check providesprotection for calls from your app to Google Maps Platform by blocking trafficthat comes from sources other than legitimate apps. It does this by checking fora token from an attestation provider. Integrating your apps with App Check helpsto protect against malicious requests, so you're not charged for unauthorizedAPI calls.

App Check integration instructions:

Handle unauthorized use of an API key

If you detect use of your API key that is unauthorized, do the following toaddress the problem:

  1. Restrict your keys: If you've used the same key in multiple apps,migrate to multiple API keys, and use separate API keys for each app. Formore details, see:

  2. If you use the Places SDK or the Maps Javascript API, you can alsouse App Check to secure your API Key.

  3. Only replace or rotate keys if the following is true:

    • You detect unauthorized usage on keys that either cannot be restrictedor are already restricted, and App Check is not applicable.

    • You want to move more quickly to secure your API key and stop the abuse,even if it might impact legitimate traffic from your application.

    Before proceeding, read throughBe careful when rotating API keys.

  4. If you are still having issues or need help,contactsupport.

Recommended application and API restrictions

The following sections suggest appropriate application and API restrictions foreach Google Maps Platform API, SDK or service.

Recommended API Restrictions

The following guidelines for API restrictions apply to allGoogle Maps Platform services:

  • Restrict your API key to only the APIs you are using it for, with thefollowing exceptions:

    • If your app uses the Places SDK for Android orPlaces SDK for iOS, authorizePlaces API (New) or Places API,depending on the SDK versions you use.1

    • If your app uses Maps JavaScript API,always authorizeit on your key.

    • If you also use any of the following Maps JavaScript APIservices, you should also authorize these corresponding APIs:

      ServiceAPI restriction
      Directions Service (Legacy)Directions API (Legacy)
      Distance Matrix Service (Legacy)Distance Matrix API (Legacy)
      Elevation ServiceElevation API
      Geocoding ServiceGeocoding API
      Place class, Place Autocomplete Widget (New) & Place Autocomplete Data API Places API (New)2
      Places Library, Places Service & Place Autocomplete Widget Places API2

1 For more details, see thePlaces SDK for AndroidandPlaces SDK for iOSdocumentation.

2 If you are unsure if you need toauthorize Places API (New) or Places API,see theMaps JavaScript APIdocumentation.

Some examples:

  • You are using the Maps SDK for Android andPlaces SDK for Android, so you include theMaps SDK for Android and Places API (New) as APIrestrictions.

  • Your website uses the Maps JavaScript APIElevation Service and theMaps Static API, so you add API restrictions for all of thefollowing APIs:

    • Maps JavaScript API
    • Elevation API
    • Maps Static API

Recommended application Restriction

Important: Restricting your API keys helps to minimize overages and billing fromunauthorized use, especially when a test environment may be or is publiclyvisible, or when an application is ready to be used in a production environment.

Websites

Tip: For Maps Embed API, seeWebsites with the Maps Embed API.

For websites using Maps JavaScript API services,Maps Static API or Street View Static API or callingrecent Google Maps Platform services directly over the HTTPS REST API orgRPC, use theWebsites application restriction:

1 For mobile applications, considerusing the nativeMaps SDK for Android andMaps SDK for iOS.

2 For mobile applications, consider usingthe nativePlaces SDK for Android andPlaces SDK for iOS.

3 See alsoProtect Static Web API usage.

Websites with the Maps Embed API

While using the Maps Embed API is no charge, you should stillrestrict any used API key to prevent abuse onother services.

Best practice: Create a separate API key for Maps Embed APIuse, and restrict this key toonly the Maps Embed API. Thisrestriction sufficiently secures the key, preventing its unauthorized use on anyother Google service. For full control over where yourMaps Embed API key can be used from, Google recommends alsoapplyingWebsites application restrictions.

If you are unable to separate your Maps Embed API usage to aseparate API key, secure your existing key using theWebsites applicationrestriction.

Apps and servers using web services

Tip: For server-side applications, Google recommends using OAuth 2.0 over API keys on the services that support it. Refer to the table below for full details.

For servers and client-side apps from trusted corporate internal networks usingweb services together with API keys, use theIP addresses applicationrestriction.

Important: IP restrictions might be impractical in some scenarios, such as inmobile applications and cloud environments that rely on dynamic IP addresses.When usingMaps web service inthese scenarios, secure your apps using aproxy server.

Use for apps and servers using these APIs:

4 For mobile applications, consider usingthe Navigation SDK.

5 For safe mobile usage, use asecure proxy server.

6 For client-side applications, considerusing the native geolocation service offered by the platform; for example,W3C Geolocation for web browsers,LocationManager or theFused Location Provider API for Android, or the AppleCore Location framework for iOS.

7 For mobile applications, consider usingthe nativePlaces SDK for Android andPlaces SDK for iOS.

8 For safe client-side usage, use asecure proxy server.

Android apps

For apps on Android, use theAndroid apps application restriction. Use forapps using these SDKs:

Important: For maximum security, Google strongly recommends that you use our native SDKs to access Google Maps Platform services from your Android application.
If you need to access Google Maps Platform services for which a native Android SDKs is not available, seeSecure client-side web service calls andProtect Static Web API usage.

In addition, prevent accidentally checking API keys into version control byusing theSecrets GradlePlugin to inject secretsfrom a local file rather than storing them in the Android Manifest.

iOS apps

For apps on iOS, use theiOS apps application restriction. Use for apps andservers using these SDKs:

Important: For maximum security, Google strongly recommend that you use our native SDKs to access Maps Platform services from your iOS application.
If you need to access Maps Platform services for which a native iOS SDKs is not available, seeSecure client-side web service calls andProtect Static Web API usage.

Further reading

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-11-21 UTC.