Эта страница переведена с помощью Cloud Translation API.

Рекомендации платформы Google Карт по безопасности
Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Приложения и проекты, использующие API и SDK платформы Google Карт, должны использовать ключи API или, если поддерживается, OAuth 2.0 для аутентификации.

Эти рекомендации покажут вам, как защитить доступ к платформе Карт.

Если вы хотите использовать OAuth 2.0 для авторизации трафика сервер-сервер , найдите тему OAuth в документации API. Подробнее см. в разделе Использование OAuth для серверных приложений .

В дополнение к применению ограничений по ключам приложений и API, следуйте всем правилам безопасности, которые применяются к определенным продуктам Google Maps Platform. Например, см. Maps JavaScript API ниже в разделе Рекомендуемые ограничения по приложениям и API .

Если ваши ключи API уже используются, ознакомьтесь с рекомендациями ниже в разделе Если вы ограничиваете используемый ключ API .

Более подробную информацию о цифровых подписях, поддерживаемых Maps Static API и Street View Static API, см. в Руководстве по цифровой подписи .

Выберите Сохранить .

Тип ограничения	Описание
Веб-сайты	Укажите один или несколько сайтов-источников перехода. Универсально поддерживаемые схемы URL-адресов реферера — `https` и `http` . Другие схемы не гарантируют корректную работу, поскольку современные веб-браузеры по соображениям конфиденциальности не отправляют заголовок `Referer` в исходящих запросах. Всегда указывайте полную строку реферера, включая схему протокола, имя хоста и необязательный порт (например, `https://google.com` ). Вы можете использовать подстановочные знаки для авторизации всех поддоменов. Например, `https://*.google.com` принимает все сайты, заканчивающиеся на `.google.com` . Будьте осторожны при разрешении полных путей рефереров, например, `https://google.com/some/path` , поскольку большинство веб-браузеров в целях конфиденциальности удаляют путь из запросов кросс-источника.
IP-адреса	Укажите один или несколько адресов IPv4 или IPv6 или подсетей с использованием нотации CIDR. IP-адреса должны соответствовать исходному адресу, который наблюдают серверы платформы Google Карт. Если вы используете преобразование сетевых адресов (NAT) , этот адрес обычно соответствует публичному IP-адресу вашего компьютера.
Android-приложения	Добавьте имя пакета Android (из файла `AndroidManifest.xml` ) и отпечаток сертификата подписи SHA-1 каждого приложения Android, которое вы хотите авторизовать. Если вы используете Play App Signing , чтобы получить отпечаток сертификата подписи, см. раздел Работа с поставщиками API . Если вы управляете собственным ключом подписи, см. раздел Самостоятельное подписание вашего приложения или обратитесь к инструкциям для вашей среды сборки.
iOS-приложения	Добавьте идентификатор пакета каждого приложения iOS, которое вы хотите авторизовать.

Установить ограничения API для ключа API

Откройте страницу учетных данных платформы Google Карт в консоли Google Cloud.
Выберите ключ API, который вы хотите ограничить.
На странице «Изменить ключ API» в разделе «Ограничения API» :
- Выберите Ограничить ключ .
- Откройте Select APIs и выберите API или SDK, к которым вы хотите предоставить доступ своему приложению с помощью ключа API.
Если API или SDK не указаны, вам необходимо включить их. Подробности см. в разделе Включение одного или нескольких API или SDK .
Выберите Сохранить .
Ограничение становится частью определения ключа API после этого шага. Убедитесь, что вы указали соответствующие данные и выберите Сохранить , чтобы сохранить ограничения ключа API. Для получения дополнительной информации см. руководство Получить ключ API в документации для конкретного API или SDK, который вас интересует.

Рекомендованные ограничения API см. в разделе Рекомендуемые ограничения API .

Проверьте использование вашего ключа API

Если вы ограничиваете ключи API после их создания или хотите узнать, какие API используются ключом, чтобы вы могли ограничить их, вам нужно проверить использование вашего ключа API. Эти шаги покажут вам, в каких службах и методах API используется ключ API. Если вы видите какое-либо использование за пределами служб платформы Google Карт, проведите исследование, чтобы определить, нужно ли вам добавить дополнительные ограничения, чтобы избежать нежелательного использования. Вы можете использовать проводник метрик консоли Google Карт Cloud, чтобы определить, какие ограничения API и приложений следует применить к вашему ключу API:

Определите API, которые используют ваш ключ API.
Выберите правильный тип ограничения приложения с помощью обозревателя метрик

Определите API, которые используют ваш ключ API.

Следующие отчеты метрик позволяют вам определить, какие API используют ваши ключи API. Используйте эти отчеты для следующих действий:

Посмотрите, как используются ваши ключи API
Отметьте неожиданное использование
Помогите проверить, безопасно ли удалять неиспользуемый ключ. Для получения информации об удалении ключа API см. Удаление неиспользуемых ключей API .

При применении ограничений API используйте эти отчеты для создания списка API для авторизации или для проверки автоматически сгенерированных рекомендаций по ограничению ключей API. Для получения дополнительной информации о рекомендуемых ограничениях см. раздел Применение рекомендуемых ограничений . Для получения дополнительной информации об использовании обозревателя метрик см. раздел Создание диаграмм с помощью обозревателя метрик .

Перейдите в проводник метрик консоли Google Cloud.
Войдите в систему и выберите проект для ключей API, которые вы хотите проверить.
Перейдите на страницу обозревателя метрик для вашего типа API:
- Для ключей API, использующих любой API , кроме Maps Embed API : перейдите на страницу обозревателя метрик .
- Для ключей API с использованием Maps Embed API : перейдите в Metrics Explorer .
Проверьте каждый ключ API:
1. Выберите ДОБАВИТЬ ФИЛЬТР .
2. Выберите метку credential_id .
3. Выберите значение , соответствующее ключу, который вы хотите проверить.
4. Обратите внимание, для каких API используется этот ключ API, и подтвердите, что такое использование ожидаемо.
5. После этого выберите фильтр в конце строки активного фильтра, чтобы удалить лишний фильтр.
Повторите эти действия для всех оставшихся клавиш.
Ограничьте свои ключи API только теми API, которые используются.
Если вы обнаружили несанкционированное использование, см. раздел Обработка несанкционированного использования ключа API .

Выберите правильный тип ограничения приложения с помощью обозревателя метрик

После проверки и принятия всех необходимых мер для обеспечения использования вашего ключа API только для используемых им служб платформы Google Карт убедитесь также, что для ключа API установлены правильные ограничения по применению.

Если ваш ключ API имеет рекомендуемые ограничения ключа API, примените их. Для получения дополнительной информации см. раздел Применить рекомендуемые ограничения ключа API .

Если ваш ключ API не имеет рекомендаций по ограничениям, определите тип ограничения приложения, который следует применить, на основе сообщенного platform_type с помощью обозревателя метрик:

Перейдите в проводник метрик консоли Google Cloud.
Войдите в систему и выберите проект для API, которые вы хотите проверить.
Перейдите на эту страницу обозревателя метрик: Обозреватель метрик .
Проверьте каждый ключ API:
1. Выберите ДОБАВИТЬ ФИЛЬТР .
2. Выберите метку credential_id .
3. Выберите значение , соответствующее ключу, который вы хотите проверить.
4. После этого выберите фильтр в конце строки активного фильтра, чтобы удалить лишний фильтр.
Повторите эти действия для всех оставшихся клавиш.
После того, как вы определили тип платформы для своих ключей API, примените ограничение приложения для этого platform_type :
PLATFORM_TYPE_JS : Применить ограничения веб-сайта к ключу.
PLATFORM_TYPE_ANDROID : Применить ограничения приложений Android к ключу.
PLATFORM_TYPE_IOS : Применить ограничения приложений iOS к ключу.
PLATFORM_TYPE_WEBSERVICE : Возможно, вам придется полагаться на ограничения IP-адреса в ключе, чтобы должным образом ограничить его.
Рекомендации по использованию Maps Static API и Street View Static API см. в разделе Protect Static Web API usage .
Рекомендации по API Maps Embed см. в разделе Веб-сайты с API Maps Embed .
Мой ключ API использует несколько типов платформ: Ваш трафик не может быть должным образом защищен с помощью одного ключа API. Вам необходимо перейти на несколько ключей API. Для получения дополнительной информации см. раздел Переход на несколько ключей API .

Используйте отдельные ключи API для каждого приложения.

Такая практика ограничивает область действия каждого ключа. Если один ключ API скомпрометирован, вы можете удалить или ротировать затронутый ключ без необходимости обновления других ключей API. Вы можете создать до 300 ключей API на проект. Для получения дополнительной информации см. Ограничения на ключи API .

Хотя один ключ API для каждого приложения идеален в целях безопасности, вы можете использовать ограниченные ключи для нескольких приложений, если они используют один и тот же тип ограничения приложений.

Применить рекомендуемые ограничения ключа API

Для некоторых владельцев проектов, редакторов и администраторов ключей API консоль Google Cloud предлагает определенные ограничения ключей API для неограниченных ключей API на основе их использования и активности на платформе Google Карт.

Если рекомендации доступны, они отображаются в виде предварительно заполненных параметров на странице учетных данных платформы Google Карт .

API и SDK платформы Google Карт, поддерживаемые автоматизированными рекомендациями

API JavaScript Карт, включая Directions Service (устаревшая версия), Distance Matrix Service (устаревшая версия), Elevation Service, Geocoding Service Класс Place, виджет автозаполнения Place (новый), API данных автозаполнения Place, библиотеку Places, Places Service и виджет автозаполнения Place
Статический API Карт и Статический API Просмотра Улиц
API встраивания карт
Maps SDK для Android, Places SDK для Android и Navigation SDK для Android
Maps SDK для iOS, Places SDK для iOS, Places Swift SDK для iOS и Navigation SDK для iOS

Причины, по которым вы можете не увидеть рекомендацию или увидеть ее неполной

Причины отсутствия рекомендаций

Вы (также) используете ключ API для служб, отличных от Google Maps Platform, или служб Maps Platform, которые еще не поддерживаются автоматическими рекомендациями.
Если вы видите использование других сервисов, не применяйте рекомендацию, не выполнив сначала следующие действия:
1. Убедитесь, что использование API, которое вы видите в обозревателе метрик консоли Google Cloud, является законным.
2. Вручную добавьте отсутствующие сервисы в список API, подлежащих авторизации.
3. Вручную добавьте любые отсутствующие ограничения приложений для служб, добавленных в список API. Если для других добавленных вами приложений потребуется другой тип ограничений приложений, см. раздел Миграция на несколько ключей API .
Ваш ключ API не используется в клиентских SDK или API.
Вы используете ключ API в малопосещаемом приложении или на веб-сайте, который не использовался в течение последних 60 дней.
Вы создали новый ключ совсем недавно или совсем недавно развернули существующий ключ в новом приложении. Если это так, просто подождите еще несколько дней, чтобы рекомендации обновились.
Вы используете ключ API в нескольких приложениях, которые требуют конфликтующих типов ограничений приложений, или вы используете один и тот же ключ API в слишком большом количестве различных приложений или веб-сайтов. В любом случае, как лучшая практика, вам следует перейти на несколько ключей. Для получения более подробной информации см. Миграция на несколько ключей API .

Причины, по которым вы видите неполную рекомендацию

Вы используете ключ API в малопосещаемом приложении или на веб-сайте, который не использовался в течение последних 60 дней.
Вы совсем недавно начали использовать существующий ключ на новом API или сервисе, и автоматический конвейер рекомендаций по ограничению ключей API еще не обработал обновленные метрики использования. Распространение метрик использования может занять несколько дней.
Если вы видите использование других сервисов, не применяйте рекомендацию, не выполнив сначала следующие действия:
1. Убедитесь, что использование API, которое вы видите в обозревателе метрик консоли Google Cloud, является законным.
2. Вручную добавьте отсутствующие сервисы в список API, подлежащих авторизации.
3. Вручную добавьте любые отсутствующие ограничения приложений для служб, добавленных в список API. Если для других добавленных вами приложений потребуется другой тип ограничений приложений, см. раздел Миграция на несколько ключей API .
4. Если вам не нужно срочно ограничить доступ к ключу, например, из-за несанкционированного использования, вы можете подождать день или два, пока рекомендации не появятся.
  Совет: в экстренной ситуации см. раздел Действия при несанкционированном использовании ключа API .

Причины, по которым вы можете видеть рекомендации, которые не видны в диаграммах

Ваше приложение или веб-сайт отправляли только очень короткие всплески трафика. В этом случае переключитесь с представления CHART на отображение TABLE или BOTH , так как использование все еще видно в легенде. Для получения дополнительной информации см. Переключение полных легенд диаграммы .
Ваш трафик идет из Maps Embed API. Инструкции см. в разделе Определение API, которые используют ваш ключ API .
Трафик из приложения или веб-сайта находится за пределами диапазона дат, доступного в обозревателе метрик консоли Google Cloud.

Применять рекомендуемые ограничения

Откройте страницу учетных данных платформы Google Карт в консоли Google Cloud.
Если доступно, выберите Применить рекомендуемые ограничения .
Примечание: Если вы не видите рекомендуемых ограничений, см. раздел Установка ограничений API для ключа API , чтобы установить соответствующие ограничения.
Выберите Проверить использование API , чтобы проверить, на каких сервисах используется ключ API. Если вы видите сервисы, отличные от Google Maps Platform, сделайте паузу , чтобы вручную просмотреть рекомендуемые шаги выше. См. шаги по устранению неполадок в начале раздела Применить рекомендуемые ограничения ключа API .
Еще раз проверьте, соответствуют ли предварительно заполненные ограничения веб-сайтам и приложениям, где вы планируете использовать свой ключ API.
Лучшая практика : документируйте и удаляйте любые ограничения приложений или API, которые не связаны с вашими службами. Если что-то сломается из-за неожиданной зависимости, вы сможете снова добавить требуемые приложения или API.
- Если вы заметили, что в вашей рекомендации явно отсутствует приложение, веб-сайт или API, добавьте его вручную или подождите пару дней, чтобы рекомендация обновилась.
- Если вам нужна дополнительная помощь с предложенной вами рекомендацией, обратитесь в службу поддержки .
Выберите Применить .

Что делать, если ваша заявка отклонена после подачи рекомендации

Если вы заметили, что приложение или веб-сайт отклоняется после применения ограничения, найдите ограничение приложения, которое необходимо добавить, в сообщении об ошибке ответа API.

Клиентские SDK и API

Приложения на основе браузера и веб-просмотра

Современные браузеры обычно редактируют заголовок Referer в запросе кросс-источника по соображениям конфиденциальности, часто убирая его до Origin . Однако точное поведение зависит от применяемой referrer-policy хостингового сайта, а также может различаться в зависимости от браузера пользователя и его версии.

Веб-приложения, использующие непрозрачные или локальные схемы URI для загрузки контента, как правило, заставляют браузер или веб-представление рендеринга полностью редактировать заголовок Referer из любых исходящих вызовов, что может привести к сбою запросов при использовании ключей API с ограничениями веб-сайта.

Дополнительные инструкции см. в разделе Размещение приложений на основе браузера на сервере .

Инструкции по устранению неполадок для приложений на базе браузера и веб-просмотра:

Подробную информацию об авторизации приложения для Maps JavaScript API см. в консоли отладки браузера.
Частично поддерживаются экзотические схемы URI. Если части вашего приложения не работают с экзотической схемой URI, даже после авторизации требуемого реферера, вам, скорее всего, придется разместить свое приложение удаленно на сервере и загрузить его по HTTPS (или HTTP).
Если вам нужна помощь с экзотическими схемами URI, обратитесь в службу поддержки .
Другие API платформы Карт обычно возвращают реферер, который необходимо авторизовать, в ответе об ошибке API, предполагая, что клиент отправил эту информацию с отклоненным запросом.
Экзотические схемы URI не поддерживаются.

Android-приложения

Используйте Android Debug Bridge (adb) или Logcat

iOS-приложения

См. Просмотр сообщений журнала.

Приложения, напрямую вызывающие веб-сервисы

Информацию о приложениях, вызывающих API HTTPS REST платформы Карт или конечные точки gRPC напрямую без клиентского SDK платформы Google Карт, см. ниже:

Приложения для Android и iOS

Если ваше приложение Android или iOS напрямую вызывает службы платформы Карт, не используя ни один из доступных клиентских SDK платформы Google Карт, см. разделы Приложения для Android и iOS для получения дополнительных советов по устранению неполадок, а также раздел Безопасные вызовы клиентских веб-служб для получения информации о современных рекомендациях по обеспечению безопасности для случаев использования на мобильных устройствах.

Если ваше приложение регистрирует ответы об ошибках API платформы Карт, приведенные выше инструкции для клиентских SDK также могут оказаться полезными для устранения неполадок аутентификации.

Серверные приложения

Приложения на стороне сервера, использующие ключи API, лучше всего защищены с помощью ограничений IP-адресов. Если вы применили ограничения IP-адресов к своему ключу и ваша служба регистрирует ответы об ошибках API платформы Карт, проверьте системные журналы для получения дополнительной информации. Ответ об ошибке будет включать IP-адрес сервера, который вам необходимо авторизовать.

Приложения на основе браузера или веб-просмотра

Хотя Maps Static API, Street View Static API и более поздние API платформы Google Карт также будут поддерживать ограничения реферера, следует отметить, что веб-браузеры или веб-представления, скорее всего, ограничат заголовок Referer Origin для запросов между источниками и, скорее всего, вообще не будут отправлять его, например, для локально доступных ресурсов или для ресурсов, обслуживаемых по протоколам, отличным от HTTP или HTTPS.

Если вы не можете использовать Maps JavaScript API в своем приложении, а ограничения веб-сайта не работают, ознакомьтесь с разделом Безопасные вызовы клиентских веб-служб, чтобы узнать, как безопасно выполнять вызовы веб-служб платформы Карт из клиентского приложения на основе браузера.

Проверка ограничений API

Чтобы проверить требуемые ограничения API, см . раздел Определение API, которые используют ваш ключ API .

Если вы не можете определить, какие ограничения следует применить:

Задокументируйте текущие ограничения для дальнейшего использования.
Удалите их временно, пока вы исследуете проблему. Вы можете проверить использование с течением времени, используя шаги в разделе Проверка использования ключа API .
При необходимости обратитесь в службу поддержки .

Удалить неиспользуемые ключи API

Прежде чем удалить ключ API, убедитесь, что он не используется в производстве. Если нет успешного трафика, ключ, скорее всего, можно безопасно удалить. Для получения дополнительной информации см. Проверка использования ключа API .

Чтобы удалить ключ API:

Откройте страницу учетных данных платформы Google Карт в консоли Google Cloud.
Выберите ключ API, который вы хотите удалить.
Нажмите кнопку «Удалить» в верхней части страницы.
На странице «Удаление учетных данных» выберите «Удалить» .
Удаление ключа API занимает несколько минут для распространения. После завершения распространения любой трафик, использующий удаленный ключ API, отклоняется.

Будьте осторожны при ротации ключей API

Ротация ключа API создает новый ключ, который имеет все ограничения старого ключа. В течение этого временного окна принимаются как старый, так и новый ключ, что дает вам возможность перенести свои приложения на использование нового ключа.

Перед ротацией ключа API :

Сначала попробуйте ограничить ваши ключи API, как описано в разделе Ограничение ваших ключей API .
Если ограничение вашего ключа API невозможно из-за конфликтующих типов ограничений приложения, выполните миграцию на несколько новых (ограниченных) ключей, как описано в разделе Миграция на несколько ключей API . Миграция позволяет вам контролировать миграцию и развертывать временную шкалу для новых ключей API.

Если предыдущие предложения невозможны и вам необходимо сменить ключ API, чтобы предотвратить несанкционированное использование, выполните следующие действия:

Откройте страницу учетных данных платформы Google Карт в консоли Google Cloud.
Откройте ключ API, который вы хотите ротировать.
В верхней части страницы выберите Повернуть ключ .
При желании измените имя ключа API.
Выберите Создать .
Обновите свои приложения, чтобы использовать новый ключ.

После обновления приложений для использования нового ключа удалите старый ключ, нажав кнопку Удалить предыдущий ключ в разделе Предыдущий ключ на странице нового ключа API.

Переход на несколько ключей API

Чтобы перейти от использования одного ключа API для нескольких приложений к использованию одного уникального ключа API для каждого приложения, выполните следующие действия:

Определите, каким приложениям нужны новые ключи :
- Веб-приложения обновлять проще всего, так как вы контролируете весь код. Планируйте обновление всех ключей ваших веб-приложений.
- С мобильными приложениями все гораздо сложнее, поскольку вашим клиентам придется обновить свои приложения, прежде чем можно будет использовать новые ключи.
Создайте и ограничьте новые ключи : добавьте как ограничение приложения, так и по крайней мере одно ограничение API. Для получения дополнительной информации см. Рекомендуемые лучшие практики .
Добавьте новые ключи в свои приложения : для мобильных приложений этот процесс может занять месяцы, пока все ваши пользователи не обновятся до последней версии приложения с новым ключом API.

Важно: Хотя вы можете защитить ключи API после их создания и использования, в мобильных приложениях (Android и iOS) ключи не заменяются, пока клиенты не обновят свои приложения. Обновление или замена ключей в приложениях JavaScript или веб-сервисов намного проще, но все равно может потребовать тщательного планирования и быстрой работы. Для получения дополнительной информации см. Если вы ограничиваете или повторно генерируете ключ API, который используется .

Разделение использования на стороне клиента и на стороне сервера на отдельные проекты

Если вам необходимо вызывать службы платформы Google Карт как из серверных приложений, так и напрямую из клиентских приложений, работающих на устройствах конечных пользователей, Google рекомендует разделить использование между двумя отдельными проектами.

Такой подход позволяет вам применять соответствующие поминутные квоты для каждого пользователя в большинстве служб платформы Google Карт в вашем клиентском проекте, помогая гарантировать, что все конечные пользователи получат свою справедливую долю от общей квоты проекта, не влияя друг на друга.

Однако, поскольку ограничения квот на пользователя влияют как на клиентские, так и на серверные приложения, если вам также требуется высокая пропускная способность для серверных заданий, создайте отдельный проект для этого варианта использования, настроенный с более высоким пределом квоты на пользователя или без него.

Отключить неиспользуемые службы

Не оставляйте неиспользуемые сервисы включенными в проекте, так как эта практика уязвима для злоупотреблений, особенно если вы не ограничили все свои открытые ключи API. В качестве лучшей практики включайте сервис в проекте только тогда, когда он нужен вашим приложениям.

Добавление ограничений API для ключа предотвращает его использование на сервисах, для которых он не был авторизован, но ограничения API применяются только к этому конкретному ключу. Отключите сервис на уровне проекта, чтобы предотвратить несанкционированное использование сервиса на любом ключе, связанном с проектом.

Используйте клиентские SDK

При использовании предоставляемых клиентских SDK платформы Google Карт вы всегда сможете применить соответствующие ограничения к своему ключу API, чтобы защитить использование сервиса.

Использование клиентских SDK также позволит вам использовать более продвинутый механизм безопасности, такой как Firebase App Check на поверхностях API Maps Platform, которые его поддерживают. Подробнее см. в разделе Использование App Check для защиты вашего ключа API .

Если клиентские SDK недоступны для вашей платформы, см. раздел Защита вызовов клиентских веб-сервисов .

Информацию о доступности клиентских SDK Google Maps Platform для различных платформ см. в разделе Рекомендуемые ограничения приложений и API .

Защита использования статического веб-API

Статические веб-API, такие как Maps Static API и Street View Static API, аналогичны вызовам API веб-сервисов.

Вы вызываете оба с помощью HTTPS REST API и обычно генерируете URL-адрес запроса API на сервере. Однако вместо возврата ответа JSON статические веб-API генерируют изображение, которое можно встроить в сгенерированный HTML-код. Что еще более важно, обычно именно клиент конечного пользователя, а не сервер, вызывает службу платформы Google Карт.

Используйте цифровую подпись

В качестве лучшей практики всегда используйте цифровые подписи в дополнение к ключу API. Также проверьте, сколько неподписанных запросов вы хотите разрешить в день, и соответствующим образом скорректируйте квоты неподписанных запросов .

Более подробную информацию о цифровых подписях можно найти в Руководстве по цифровым подписям .

Защитите свою тайну подписи

Чтобы защитить статические веб-API, не встраивайте секреты подписи API напрямую в код или в исходное дерево, и не раскрывайте их в клиентских приложениях. Следуйте этим рекомендациям по защите секретов подписи:

Сгенерируйте подписанные URL-адреса запросов Maps Static API и Street View Static API на стороне сервера при обслуживании веб-страницы или в ответ на запрос из вашего мобильного приложения .
Для статического веб-контента вы можете использовать виджет «Подписать URL сейчас» на странице учетных данных платформы Google Карт Cloud Console.
Для динамического веб-контента см. доступные примеры кода подписи URL-запросов.
Совет: разработчики мобильных приложений могут использовать защищенный прокси-сервер для генерации подписанных запросов.
Храните секреты подписи вне исходного кода и исходного дерева вашего приложения . Если вы помещаете свои секреты подписи или любую другую личную информацию в переменные среды или включаете файлы, которые хранятся отдельно, а затем делитесь своим кодом, то секреты подписи не включаются в общие файлы. Если вы храните секреты подписи или любую другую личную информацию в файлах, храните файлы вне исходного дерева вашего приложения, чтобы ваши секреты подписи не попали в вашу систему управления исходным кодом. Эта мера предосторожности особенно важна, если вы используете публичную систему управления исходным кодом, такую как GitHub.

Защитите ключи API веб-сервиса

Для безопасного использования API и служб платформы Google Карт из клиентских приложений см. разделы Использование клиентских SDK и Безопасные вызовы клиентских веб-служб .

Храните ключи API вне исходного кода или исходного дерева вашего приложения . Если вы помещаете ключи API или любую другую информацию в переменные среды или включаете файлы, которые хранятся отдельно, а затем делитесь своим кодом, ключи API не включаются в общие файлы. Это особенно важно, если вы используете публичную систему управления исходным кодом, например GitHub.

Чтобы помочь защитить ключ API веб -службы от случайного использования, Google рекомендует применить ограничения API к любому ключу, используемому для платформы Maps. Кроме того, также применение ограничений IP -адреса к ключу веб -службы защитит его от помощи защитить его от несанкционированного использования с других источников IP -адресов, даже если ключ случайно протекает.

Используйте OAuth для приложений на стороне сервера

OAuth 2.0 является открытым стандартом для делегирования доступа.

В то время как протокол OAuth 2.0 поддерживает варианты использования, когда конечный пользователь разрешает приложение для доступа к персональным данным от их имени, предполагаемый вариант использования для OAuth 2.0 с платформой MAPS заключается в том, чтобы разработчик использовал токены временного доступа для разрешения своего заявления на вызов API на отделах своей учетной записи Google Cloud Project с разрешения на сервисную учетную запись.

Поскольку учетная запись сервиса может иметь чрезвычайно широкие разрешения, OAuth 2.0 рекомендуется для авторизации вызовов сервера к серверу между доверенными приложениями на стороне сервера разработчика и серверами платформ Google Maps.

Для клиентских приложений, работающих на устройствах конечных пользователей, рекомендуются другие методы аутентификации, такие как клавиши API.

Если вы хотите использовать OAuth 2.0 для авторизации трафика сервера к серверу, ищите тему OAuth в вашей документации API.

Например, вот тема OAuth для API проверки адреса .

Безопасные вызовы веб-службы на стороне клиента

Если SDK на стороне клиента недоступны , см. Рекомендации ниже.

Используйте прокси-сервер

Использование безопасного прокси-сервера обеспечивает надежный источник для взаимодействия с конечной точкой веб-службы платформы Google Maps из приложения на стороне клиента, не выявляя ключ API, подпись секрет или учетную запись Cloud Service Google неавторизованным пользователям.

Ключевые моменты:

*   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.

Для получения дополнительной информации об использовании прокси -сервера см. В живых: использование прокси -серверов с клиентскими библиотеками Google Data API .

Защита прямых вызовов мобильных веб -сервисов

Если вы не можете настроить защищенный прокси-сервер для вашего приложения на стороне клиента, защитите свое приложение, используя следующие шаги:

Используйте заголовки HTTP:
- Android : используйте заголовки X-Android-Package и X-Android-Cert HTTP.
- iOS : используйте заголовок X-Ios-Bundle-Identifier HTTP.
Добавьте соответствующие ограничения приложения в свой ключ Android или iOS.
ВАЖНО: Ограничения приложений Android и iOS не могут быть полностью поддержаны на старых Legacy Google Maps Platform Services.
Прежде чем рассмотреть вопрос о выдаче звонков непосредственно из вашего мобильного приложения в веб -сервис API Platform Platform Platform Platform Platform, убедитесь, что запросы с неправильными идентификаторами приложений Android или iOS отклоняются.
Если ограничения приложений Android и iOS не поддерживаются в тестируемой конечной точке, Google настоятельно рекомендует использовать защищенный прокси -сервер между вашим мобильным клиентом и конечной точкой веб -службы платформы Google Maps.

Советы для приложений Android:

Прежде чем интегрировать свое приложение для Android с службами платформы Google Maps, убедитесь, что ваш идентификатор приложения (также называемый имя пакета) отформатируется правильно. Для получения подробной информации см. Модуль «Настроить приложение» . В документации Android.
Чтобы пройти X-Android-Package непосредственно из вашего приложения, ищите его программно, используя Context.getPackageName() .
Чтобы пройти X-Android-Cert непосредственно из ваших приложений, рассчитайте необходимый отпечаток пальца SHA-1 ваших сертификатов подписи приложения, доступных через PackageInfo.signingInfo .
Важно: убедитесь, что вы передаете дивариюр SHA-1 в сертификате подписания, и конвертируете полученную 20-байтовую дайджест в кодируемую строку BASE16 (шестнадцатеричный) без каких-либо разделителей или префиксов при установке заголовка, EG, 00112233445566778899AABBCCDDEEFF00112233
Если вы авторизуете свое приложение для Android, используя Cloud Console Google, обратите внимание, что пользовательский интерфейс ожидает, что отпечаток пальца SHA-1 станет строкой, дающей толстой кишкой, например, 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33 Тем не менее, инструмент gcloud и API API -клавиш ожидают шестнадцатеричную строку без разделителей.

Советы для приложений iOS:

Прежде чем интегрировать свое приложение для iOS с службами платформы Google Maps, убедитесь, что ваш идентификатор пакета отформатируется правильно .
Обычно вы должны всегда проходить идентификатор пакета вашего основного пакета в заголовке X-Ios-Bundle-Identifier , при разрешении вашего приложения для iOS.

Для получения дополнительной информации см. В статьях управление клавишами API и используйте клавиши API для доступа к API .

Разделяйте приложения на основе браузера на сервере

Frameworks, такие как Apache Cordova, позволяют вам удобно создавать многоплатформенные гибридные приложения, работающие внутри веб-просмотра. Тем не менее, ограничения веб -сайта API -ключа не гарантируются правильно, если только ваше веб -приложение не будет загружено с использованием HTTP или HTTP с веб -сайта, который вы контролируете и разрешаете.

В комплекте ресурсы, загруженные локально из гибридного приложения, или доступ с использованием локального URL -адреса файла во многих случаях не позволят авторизации на основе рефералов работать, поскольку питание двигателя браузера, питание вашего WebView, будет опустить отправку заголовка Referer . Чтобы избежать этого, размещайте серверную сторону веб-приложений, а не на стороне клиента.

В качестве альтернативы, для мобильных приложений, рассмотрите возможность использования доступной нативной платформы Google Maps Android и iOS SDK, вместо использования веб -SDK.

Используйте проверку приложения, чтобы закрепить ключ API

Некоторые карты SDK и API позволяют интегрироваться с проверкой приложений Firebase . Проверка приложения обеспечивает защиту для вызовов из вашего приложения на платформу Google Maps, блокируя трафик, который поступает из источников, отличных от законных приложений. Это делает это путем проверки токена от поставщика аттестации. Интеграция ваших приложений с помощью проверки приложений помогает защитить от вредоносных запросов, поэтому вам не предъявлено обвинение за несанкционированные вызовы API.

Приложения проверяют инструкции по интеграции:

Обрабатывать несанкционированное использование ключа API

Если вы обнаружите использование своего ключа API, который неавторизован, сделайте следующее, чтобы решить проблему:

Ограничьте свои ключи : если вы использовали один и тот же ключ в нескольких приложениях, перейдите в несколько клавиш API и используйте отдельные клавиши API для каждого приложения. Для получения более подробной информации см.:
Если вы используете места SDK или API Maps JavaScript, вы также можете использовать проверку приложения для обеспечения ключа API .
Замените или поверните клавиши, только если следующее верно:
- Вы обнаруживаете несанкционированное использование на ключах, которые либо не могут быть ограничены, либо уже ограничены, а проверка приложений не применима.
- Вы хотите двигаться быстрее, чтобы обеспечить свой ключ API и остановить злоупотребление, даже если это может повлиять на законное трафик из вашего заявления.
Прежде чем продолжить, прочитайте , будьте осторожны при вращении клавиш API .
Если у вас все еще есть проблемы или нужна помощь, свяжитесь с поддержкой .

Услуга	API-ограничение
Служба направления (наследие)	Направления API (Legacy)
Служба дистанционной матрицы (наследие)	API матрицы расстояния (Legacy)
Услуга возвышения	API высоты
Геокодирование	API геокодирования
Заместите класс, разместите виджет автозаполнения (новый) и поместите API данных AutoComplete Data	Места API (новый) ²
Библиотека мест, места обслуживания и автозаполнения.	Размещает API ²

Тип ограничения	Описание
Веб-сайты	Укажите один или несколько веб -сайтов рефералов. Унидильно поддерживаемые схемы направления URI - `https` и `http` . Другие схемы не гарантированно работают правильно, поскольку современные веб -браузеры будут по соображениям конфиденциальности, а не отправят заголовок «реферера» в исходящих запросах. Всегда предоставляйте всю строку реферера, включая схему протокола, имя хоста и необязательный порт (например, `https://google.com` ). Вы можете использовать символы подстановочных знаков для авторизации всех субдоменов. Например, `https://*.google.com` принимает все сайты, заканчивающиеся на `.google.com` . Будьте осторожны при разрешении реферателей с полным пути, например, `https://google.com/some/path` , так как большинство веб-браузеры будут по причинам конфиденциальности, пройдя путь от перекрестных запросов.
IP-адреса	Укажите один или несколько адресов IPv4 или IPv6, или подсети, используя нотацию CIDR. IP -адреса должны соответствовать исходному адресу, который наблюдают серверы платформы Google Maps. Если вы используете перевод сетевого адреса (NAT) , этот адрес обычно соответствует публичному IP -адресу вашей машины.
Android-приложения	Добавьте имя пакета Android (из файла `AndroidManifest.xml` ) и сертификат подписи SHA-1 от каждого отпечатка пальца Android, который вы хотите разрешить. Если вы используете подписание приложения Play , чтобы получить отпечаток Finger Signing, см. Работа с поставщиками API . Если вы управляете своим собственным ключом подписания, см. Саморезокубление вашего приложения или обратитесь к инструкциям для вашей среды сборки.
iOS-приложения	Добавьте идентификатор пакета каждого приложения для iOS, который вы хотите разрешить.

Откройте страницу Google Cloud Console Google Maps Platform Plateries .
Если доступно, выберите «Применить рекомендуемые ограничения» .
ПРИМЕЧАНИЕ. Если вы не видите никаких рекомендуемых ограничений, см. Установленные ограничения API для ключа API для установки соответствующих ограничений.
Выберите «Проверьте использование API» , чтобы проверить, на какие услуги используется ключ API. Если вы видите, кроме служб платформы Google Maps, сделайте паузу для вручную просмотреть шаги рекомендации выше. См. Шаги по устранению неполадок в начале раздела Примените рекомендуемые ограничения ключа API .
Double-check that the pre-filled restrictions match the websites and apps where you expect to use your API key.
Best Practice : Document and remove any application or API restrictions that are not affiliated with your services. If something breaks due to an unexpected dependency, then you can add the required apps or APIs back in.
- If you recognize that an app, website or API is clearly missing from your recommendation, add it manually or wait a couple of days to allow the recommendation to update.
- If you need further help with your suggested recommendation, contact support .
Выберите Применить .

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 error message.

Client-side SDKs and APIs

Browser and webview based apps

Modern browsers typically redact the Referer header in cross-origin request for privacy reasons, often stripping it down to the Origin . However, the exact behavior depends on the applied referrer-policy of the hosting site, and may also vary, based on the user browser and version.

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

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

Troubleshooting instructions for browser and webview based apps:

For Maps JavaScript API, see the browser debug console for details on how to authorize your application.
Exotic URI schemes are partially supported. If parts of your application don't work it an exotic URI scheme, even after authorizing the required referrer, you will likely need to host your application remotely 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 the referrer you need to authorize in the API error response, presuming the client sent this information with the rejected request.
Exotic URI schemes are not supported.

Android-приложения

Use Android Debug Bridge (adb) or Logcat

iOS-приложения

See Viewing Log Messages

Apps calling web services directly

For applications calling Maps Platform HTTPS REST API or gRPC endpoints directly without a client-side Google Maps Platform SDK, see below:

Приложения для Android и iOS

If your Android or iOS application calls Maps Platform services directly without using any of the available Google Maps Platform client SDKs, see Android apps and iOS apps for further troubleshooting tips, and Secure client-side web service calls for current best security practices for mobile use cases.

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

Server-side apps

Server-side applications relying on API keys are best secured through IP address restrictions. If you have applied IP address restrictions to your key, and your service logs Maps Platform API error responses, check your system logs for further information. The error response will include the server IP address that you need to authorize.

Browser or webview based apps

While Maps Static API, Street View Static API more recent Google Maps Platform APIs will also support referrer restrictions, note that web browsers or webviews will likely restrict the Referer header to the Origin for cross-origin requests, and will likely omiy sending it altogether, eg, for locally accessed resources, or for 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, see Secure client-side web service calls for how to issue Maps Platform web service calls securely from within your browser based client-side application.

Checking API restrictions

To check your required API restrictions, see Determine the APIs that use your API key .

If you are unable to determine which restrictions to apply:

Document the current restrictions for future reference.
Remove them temporarily while you investigate the issue. You can check your usage over time using the steps in Check your API key usage .
If needed, contact support .

Delete unused API keys

Before you delete an API key, make sure that it is not used in production. If there is no successful traffic, the key is likely safe to delete. For more information, see Check your API key usage .

To delete an API key:

Open the Google Cloud console Google Maps Platform Credentials page.
Select the API key you want to delete.
Select the Delete button near the top of the page.
On the Delete credential page, select Delete .
Deleting an API key takes a few minutes to propagate. After propagation completes, any traffic using the deleted API key is rejected.

Be careful when rotating API keys

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 a chance to migrate your apps to use the new key.

Before rotating an API key :

First try to restrict your API keys as described in Restrict your API keys .
If restricting your API key is not possible due to conflicting application restriction types, migrate to multiple new (restricted) keys as described in Migrate to multiple API keys . Migrating lets 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 API key to prevent unauthorized use, then follow these steps:

Open the Google Cloud console Google Maps Platform Credentials page.
Open the API key you want to rotate.
At the top of the page, select Rotate key .
Optionally, change the API key name.
Выберите Создать .
Update your applications to use the new key.

After you have updated your applications to using the new key, delete the old key by clicking the Delete the previous key button under the Previous Key section of the new API key page.

Migrate to multiple API keys

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

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 apps before the new keys can be used.
Create and restrict the new keys : Add both an application restriction and at least one API restriction. For more information, see Recommended best practices .
Add the new keys to your apps : For mobile apps, this process may take months until all of your users update to the latest app with the new API key.

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

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

This approach lets you apply appropriate per-minute, per-user quota limits on most Google Maps Platform services on your client-side project, helping ensure all end users get their fair share fair of your overall project quota without impacting each other.

However, since per-user quota restrictions impact both client-side and server-side applications, if you also require high bandwidth for your server-side jobs, set up a separate project for this use case, configured with a higher, or no, per-user quota limit.

Disable unused services

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

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

Use client-side SDKs

When using provided client-side Google Maps Platform SDKs, you will always be able 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 security mechanism, such as Firebase App Check on the Maps Platform API surfaces that support it. See Use App Check to secure your API key for further details.

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

For the availability of client-side Google Maps Platform SDKs for different platforms, see Recommended application and API restrictions .

Protect Static Web API usage

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

You call both using an HTTPS REST API, and you typically generate the API request URL on the server. However, instead of returning a JSON response, Static Web APIs generate an image that you can embed in generated HTML code. More importantly, it is generally the end-user client , not the server, that calls the Google Maps Platform service.

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 and adjust your unsigned request quotas accordingly.

For more details about digital signatures, see the Digital Signature Guide .

Protect your signing secret

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

Generate your signed Maps Static API and Street View Static API request URLs server-side when serving a web page, or in response to a request from your mobile application .
For static web content, you can use the Sign a URL now widget on the Cloud Console Google Maps Platform Credentials page.
For dynamic web content, see the available URL request signing code samples .
Tip: Mobile developers could use a secure proxy server for generating their signed requests.
Store signing secrets outside of your application's source code and source tree . If you put your signing secrets or any other private information in environment variables or include files that are stored separately and then share your code, then signing secrets are not included in the shared files. If you store signing secrets or any other private information in files, keep the files outside your application's source tree to keep your signing secrets out of your source code control system. This precaution is particularly important if you use a public source code management system, such as GitHub.

Protect web service API keys

For secure use of Google Maps Platform APIs and services from client-side apps, see Use client-side SDKs and Secure 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 or include files that are stored separately and then share your code, the API keys are not included in the shared files. This is particularly important if you use a public source code management system, such as GitHub.

To help shield your web service API key against accidental use, Google recommends applying API restrictions to any key used for Maps Platform. Furthermore, also applying IP address restrictions to your web service key will protect it against help protect it against unauthorized use from other source IP addresses, even if the key accidentally leaks.

Use OAuth for server-side apps

OAuth 2.0 is an open standard for access delegation.

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

As a service account may have extremely broad permissions, OAuth 2.0 is recommended for authorizing server-to-server calls between a developer's trusted server-side applications and Google's Maps Platform servers.

For client-side applications running on end user devices, other authentication methods, 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 OAuth topic for the Address Validation API .

Secure client-side web service calls

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

Используйте прокси-сервер

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

Ключевые моменты:

*   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.

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

Secure direct mobile web service calls

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

Use HTTP headers:
- Android : Use the X-Android-Package and X-Android-Cert HTTP headers.
- iOS : Use the X-Ios-Bundle-Identifier HTTP header.
Add the corresponding application restrictions to your Android or iOS key.
Important: Android and iOS application restrictions may not be fully supported on older legacy Google Maps Platform services.
Before you consider issuing calls directly from your mobile application to a Google Maps Platform REST API web service, verify that requests with incorrect Android or iOS application identifiers are rejected.
If Android and iOS application restrictions are not supported on the tested endpoint, Google strongly recommends that you use a secure proxy server between your mobile clients and the Google Maps Platform web service endpoint.

Tips for Android applications:

Before you integrate your Android application with Google Maps Platform services, verify that your application ID (also called package name) is formatted correctly. For details, see Configure app module . in the Android documentation.
To pass X-Android-Package directly from your application, look it up programmatically using Context.getPackageName() .
To pass X-Android-Cert directly from your applications, calculate the required SHA-1 fingerprint of your application signing certificates, accessible through PackageInfo.signingInfo .
Important: Make sure that you pass the SHA-1 digest of the signing certificate, and convert the resulting 20-byte digest to a Base16 (hexadecimal) encoded string without any delimiters or prefixes when setting the header, eg, 00112233445566778899AABBCCDDEEFF00112233 .
If you authorize your Android application using the Google Cloud console, note that the UI expects the SHA-1 fingerprint to be a colon-delimited string, eg, 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33 . However, the gcloud tool and the API keys API expect the hexadecimal string without delimiters.

Tips for iOS applications:

Before you integrate your iOS application with Google Maps Platform services, verify that your Bundle ID is formatted correctly .
You should typically always pass the Bundle ID of your main bundle in the X-Ios-Bundle-Identifier header, when authorizing your iOS application.

For further information, refer to articles Manage API keys and Use API keys to access APIs .

Host your browser based apps on a server

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.

Use App Check to secure your API key

Certain Maps SDKs and APIs allow you to integrate with Firebase App Check . App Check provides protection for calls from your app to Google Maps Platform by blocking traffic that comes from sources other than legitimate apps. It does this by checking for a token from an attestation provider. Integrating your apps with App Check helps to protect against malicious requests, so you're not charged for unauthorized API 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 to address the problem:

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. For more details, see:
If you use the Places SDK or the Maps Javascript API, you can also use App Check to secure your API Key .
Only replace or rotate keys if the following is true:
- You detect unauthorized usage on keys that either cannot be restricted or 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 through Be careful when rotating API keys .
If you are still having issues or need help, contact support .

Recommended application and API restrictions

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

Recommended API Restrictions

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

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

If your app uses Maps JavaScript API, always authorize it on your key.

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

Услуга	API-ограничение
Directions Service (Legacy)	Directions API (Legacy)
Distance Matrix Service (Legacy)	Distance Matrix API (Legacy)
Elevation Service	API высоты
Geocoding Service	API геокодирования
Place class, Place Autocomplete Widget (New) & Place Autocomplete Data API	Places API (New) ²
Places Library, Places Service & Place Autocomplete Widget	Places API ²

¹ For more details, see the Places SDK for Android and Places SDK for iOS documentation.

² If you are unsure if you need to authorize Places API (New) or Places API, see the Maps JavaScript API documentation.

Вот несколько примеров:

You are using the Maps SDK for Android and Places SDK for Android, so you include the Maps SDK for Android and Places API (New) as API restrictions.
Your website uses the Maps JavaScript API Elevation Service and the Maps Static API, so you add API restrictions for all of the following APIs:
- API JavaScript Карт
- API высоты
- Статический API Карт

Recommended application Restriction

Веб-сайты

For websites using Maps JavaScript API services, Maps Static API or Street View Static API or calling recent Google Maps Platform services directly over the HTTPS REST API or gRPC, use the Websites application restriction:

¹ For mobile applications, consider using the native Maps SDK for Android and Maps SDK for iOS .

² For mobile applications, consider using the native Places SDK for Android and Places SDK for iOS .

³ See also Protect Static Web API usage .

Websites with the Maps Embed API

While using the Maps Embed API is no charge, you should still restrict any used API key to prevent abuse on other services.

Best practice : Create a separate API key for Maps Embed API use, and restrict this key to only the Maps Embed API. This restriction sufficiently secures the key, preventing its unauthorized use on any other Google service. For full control over where your Maps Embed API key can be used from, Google recommends also applying Websites application restrictions.

If you are unable to separate your Maps Embed API usage to a separate API key, secure your existing key using the Websites application restriction.

Apps and servers using web services

For servers and client-side apps from trusted corporate internal networks using web services together with API keys, use the IP addresses application restriction.

Use for apps and servers using these APIs:

⁴ For mobile applications, consider using the Navigation SDK.

⁵ For safe mobile usage, use a secure proxy server .

⁶ For client-side applications, consider using the native geolocation service offered by the platform; for example, W3C Geolocation for web browsers, LocationManager or the Fused Location Provider API for Android, or the Apple Core Location framework for iOS.

⁷ For mobile applications, consider using the native Places SDK for Android and Places SDK for iOS .

⁸ For safe client-side usage, use a secure proxy server .

Android-приложения

For apps on Android, use the Android apps application restriction. Use for apps using these SDKs:

In addition, prevent accidentally checking API keys into version control by using the Secrets Gradle Plugin to inject secrets from a local file rather than storing them in the Android Manifest.

iOS-приложения

For apps on iOS, use the iOS apps application restriction. Use for apps and servers using these SDKs:

Рекомендации платформы Google Карт по безопасности Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Рекомендуемые лучшие практики

Рекомендуется для всех вариантов использования ключей API

Дополнительные рекомендации для клиентских приложений

Дополнительные рекомендации для веб-сайтов или клиентских приложений, использующих статические веб-API

Дополнительные рекомендации для серверных приложений, использующих веб-сервисы

Если вы ограничиваете или ротируете используемый ключ API

Дополнительная информация

Ограничьте свои ключи API

Установить ограничение приложения для ключа API

Установить ограничения API для ключа API

Проверьте использование вашего ключа API

Определите API, которые используют ваш ключ API.

Выберите правильный тип ограничения приложения с помощью обозревателя метрик

Используйте отдельные ключи API для каждого приложения.

Применить рекомендуемые ограничения ключа API

API и SDK платформы Google Карт, поддерживаемые автоматизированными рекомендациями

Причины, по которым вы можете не увидеть рекомендацию или увидеть ее неполной

Причины отсутствия рекомендаций

Причины, по которым вы видите неполную рекомендацию

Причины, по которым вы можете видеть рекомендации, которые не видны в диаграммах

Применять рекомендуемые ограничения

Что делать, если ваша заявка отклонена после подачи рекомендации

Клиентские SDK и API

Приложения, напрямую вызывающие веб-сервисы

Проверка ограничений API

Удалить неиспользуемые ключи API

Будьте осторожны при ротации ключей API

Переход на несколько ключей API

Разделение использования на стороне клиента и на стороне сервера на отдельные проекты

Отключить неиспользуемые службы

Используйте клиентские SDK

Защита использования статического веб-API

Используйте цифровую подпись

Защитите свою тайну подписи

Защитите ключи API веб-сервиса

Используйте OAuth для приложений на стороне сервера

Безопасные вызовы веб-службы на стороне клиента

Используйте прокси-сервер

Защита прямых вызовов мобильных веб -сервисов

Разделяйте приложения на основе браузера на сервере

Используйте проверку приложения, чтобы закрепить ключ API

Обрабатывать несанкционированное использование ключа API

Рекомендуемые ограничения приложения и API

Рекомендуемые ограничения API

Рекомендуемое ограничение приложения

Веб-сайты

Веб -сайты с картами встраивают API

Приложения и серверы с использованием веб -сервисов

Android-приложения

iOS-приложения

Дальнейшее чтение

Рекомендуемые лучшие практики

Рекомендуется для всех использования ключей API

Дополнительные рекомендации для приложений на стороне клиента

Дополнительные рекомендации для веб-сайтов или приложений на стороне клиента с использованием статических веб-API

Дополнительные рекомендации для приложений на стороне сервера с использованием веб-сервисов

Если вы ограничиваете или вращаете ключ API, который используется

Дополнительная информация

Ограничьте свои клавиши API

Установите ограничение приложения для ключа API

Установите ограничения API для ключа API

Проверьте использование ключа API

Определите API, которые используют ваш ключ API

Выберите правильный тип ограничения приложения, используя проводник метрик

Используйте отдельные клавиши API для каждого приложения

Применить рекомендуемые ограничения ключа API

Google Maps Platform API и SDK, поддерживаемые автоматизированными рекомендациями

Причины вы не можете увидеть рекомендацию или неполную

Причины не видеть рекомендации

Причины для просмотра неполной рекомендации

Причины вы можете увидеть рекомендации, которые не видны в чартах

Для применения рекомендуемых ограничений

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

Client-side SDKs and APIs

Apps calling web services directly

Checking API restrictions

Delete unused API keys

Be careful when rotating API keys

Migrate to multiple API keys

Рекомендации платформы Google Карт по безопасности
Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.