Рекомендации платформы Google Карт по безопасности

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

Эти рекомендации помогут вам обеспечить безопасность доступа к платформе карт.

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

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

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

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

Рекомендуемые передовые методы

Для повышения безопасности и во избежание выставления счетов за несанкционированное использование, следуйте этим рекомендациям по обеспечению безопасности API для всех API, SDK и сервисов платформы Google Maps:

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

Ограничьте использование ваших API-ключей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Дополнительные инструкции см. в разделе «Переход на использование нескольких ключей API» .

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

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

  Для получения дополнительной информации см. раздел «Обработка несанкционированного использования ключа API» .

Более подробная информация

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

Ограничьте использование ваших API-ключей

Рекомендуется всегда ограничивать использование API-ключей одним типом ограничений для приложений и одним или несколькими ограничениями для API. Рекомендации по ограничениям для API, SDK или JavaScript-сервисов см. в разделе «Рекомендуемые ограничения для приложений и API» ниже.

• Ограничения для приложений. Вы можете ограничить использование ключа API определенными платформами: приложениями Android или iOS, определенными веб-сайтами для клиентских приложений или определенными IP-адресами или подсетями CIDR для серверных приложений, выполняющих вызовы REST API веб-сервисов.

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

• Ограничения API. Вы можете ограничить использование вашего ключа API для определенных API, SDK или сервисов платформы Google Maps. Ограничения API разрешают запросы только к указанным вами API и SDK. Для каждого ключа API можно указать столько ограничений, сколько необходимо. Список доступных API включает все API, включенные в проекте.

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

1. Откройте страницу «Учетные данные платформы Google Maps» в консоли Google Cloud.

2. Выберите ключ API, доступ к которому вы хотите ограничить.

3. На странице редактирования ключа API в разделе «Ограничения ключа» выберите «Установить ограничение для приложения» .

   

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

   Тип ограничения	Описание
   Веб-сайты	Укажите один или несколько сайтов-источников перехода. Универсально поддерживаемыми схемами URI для рефереров являются https и http . Работа других схем не гарантирует корректной работы, поскольку современные веб-браузеры по соображениям конфиденциальности не отправляют заголовок `Referer` в исходящих запросах. Всегда указывайте полную строку источника перехода, включая схему протокола, имя хоста и, при необходимости, порт (например, 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, которое вы хотите авторизовать. Выберите приложения для Android . Нажмите + Добавить . Введите имя пакета и отпечаток сертификата SHA-1. Например: com.example.android.mapexample BB:0D:AC:74:D3:21:E1:43:67:71:9B:62:91:AF:A1:66:6E:44:5D:75 Нажмите « Сохранить ». Существует два типа сертификатов: Отладочный сертификат : Используйте этот тип сертификата только для тестируемых приложений и другого кода, не предназначенного для производственной среды. Не пытайтесь опубликовать приложение, подписанное отладочным сертификатом. Инструменты Android SDK автоматически генерируют этот сертификат при запуске отладочной сборки. Сертификат для выпуска : Используйте этот сертификат, когда будете готовы выпустить свое приложение в магазин приложений. Инструменты Android SDK генерируют этот сертификат при запуске сборки для выпуска. Для получения дополнительной информации о подписании приложений Android и сертификатах см. руководство «Подпишите свое приложение» . Если вы используете функцию подписи приложений Play , чтобы получить отпечаток сертификата подписи, см. раздел «Работа с поставщиками API» . Если вы управляете собственным ключом подписи, см. раздел «Самоподписание приложения» или обратитесь к инструкциям для вашей среды сборки.
   приложения для iOS	Добавьте идентификатор пакета каждого iOS-приложения, которое вы хотите авторизовать. Выберите приложения для iOS . Нажмите + Добавить . Добавьте идентификатор пакета, чтобы принимать запросы от iOS-приложения с этим идентификатором. Нажмите « Сохранить ».

   Рекомендации по ограничению использования приложения см. в разделе «Рекомендуемые ограничения использования приложения» .

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

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

1. Откройте страницу «Учетные данные платформы Google Maps» в консоли Google Cloud.

2. Выберите ключ API, доступ к которому вы хотите ограничить.

3. На странице редактирования ключа API , в разделе «Ограничения API» :

   • Выберите «Ограничить ключ» .

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

   Если API или SDK не указаны в списке, их необходимо включить. Подробнее см. раздел «Включение одного или нескольких API или SDK» .

   

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

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

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

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

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

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

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

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

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

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

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

1. Перейдите в раздел «Обозреватель метрик» в консоли Google Cloud.

2. Войдите в систему и выберите проект, для которого хотите проверить ключи API.

3. Перейдите на страницу обозревателя метрик для вашего типа API:

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

   • Для получения ключей API, используемых с Maps Embed API , перейдите в раздел «Обозреватель метрик» .

4. Проверьте каждый ключ API:

   1. Выберите «ДОБАВИТЬ ФИЛЬТР» .

   2. Выберите метку credential_id .

   3. Выберите значение , соответствующее ключу, который вы хотите проверить.

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

   5. После этого выберите «Удалить фильтр» delete в конце строки активного фильтра, чтобы удалить лишний фильтр.

5. Повторите то же самое для всех оставшихся ключей.

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

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

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

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

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

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

1. Перейдите в раздел «Обозреватель метрик» в консоли Google Cloud.

2. Войдите в систему и выберите проект, для которого хотите проверить API.

3. Перейдите на эту страницу обозревателя метрик: Обозреватель метрик .

4. Проверьте каждый ключ API:

   1. Выберите «ДОБАВИТЬ ФИЛЬТР» .

   2. Выберите метку credential_id .

   3. Выберите значение , соответствующее ключу, который вы хотите проверить.

   4. После этого выберите «Удалить фильтр» delete в конце строки активного фильтра, чтобы удалить лишний фильтр.

5. Повторите то же самое для всех оставшихся ключей.

6. Получив тип платформы для ваших API-ключей, примените ограничение приложения для этого platform_type :

   PLATFORM_TYPE_JS : Применить ограничения веб-сайта к этому ключу.

   PLATFORM_TYPE_ANDROID : Применить ограничения для приложений Android к этому ключу.

   PLATFORM_TYPE_IOS : Применить ограничения для iOS-приложений к ключу.

   PLATFORM_TYPE_WEBSERVICE : Возможно, вам придется полагаться на ограничения по IP-адресу для ключа, чтобы обеспечить его корректное использование.

   Рекомендации по использованию статического API карт и статического API просмотра улиц см. в разделе «Защита использования статического веб-API» .

   Рекомендации по использованию API для встраивания карт см. в разделе «Веб-сайты, использующие API для встраивания карт» .

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

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

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

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

Примените рекомендуемые ограничения на использование API-ключей.

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

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

Автоматизированные рекомендации поддерживают API и SDK платформы Google Maps.

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

• Статический API карт и статический API просмотра улиц

• API для встраивания карт

• Maps SDK для Android, Navigation SDK для Android, Places SDK для Android и Places UI Kit для Android

• Maps SDK для iOS, Navigation SDK для iOS, Places SDK для iOS, Places Swift SDK для iOS и Places UI Kit для iOS.

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

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

• Вы также используете ключ API не только на сервисах платформы Google Maps, но и на сервисах платформы Maps, которые еще не поддерживаются автоматическими рекомендациями.

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

  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 встраивания карт. Инструкции см. в разделе «Определение API, использующих ваш ключ API» .

• Трафик из приложения или веб-сайта выходит за пределы диапазона дат, доступного в инструменте «Обозреватель метрик» консоли Google Cloud.

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

1. Откройте страницу «Учетные данные платформы Google Maps» в консоли Google Cloud.

2. Если доступно, выберите «Применить рекомендуемые ограничения» .

   

3. Выберите «Проверить использование API» , чтобы убедиться, для каких сервисов используется ключ API. Если вы видите сервисы, отличные от Google Maps Platform, сделайте паузу и вручную проверьте рекомендации, описанные выше. См. шаги по устранению неполадок в начале раздела «Применение рекомендуемых ограничений для ключа API» .

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

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

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

   • Если вам потребуется дополнительная помощь с предложенной рекомендацией, обратитесь в службу поддержки .

5. Выберите «Применить» .

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

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

SDK и API на стороне клиента

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

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

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

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

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

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

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

  Если вам нужна помощь с экзотическими схемами URI, обратитесь в службу поддержки .

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

  Экзотические схемы URI не поддерживаются.

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

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

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

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

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

Для приложений, напрямую обращающихся к HTTPS REST API или gRPC-конечным точкам платформы Maps без клиентского SDK Google Maps Platform, см. ниже:

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

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

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

Приложения на стороне сервера

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

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

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

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

Советы по проверке ограничений API

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

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

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

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

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

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

1. Откройте страницу «Учетные данные платформы Google Maps» в консоли Google Cloud.

2. Выберите ключ API, который хотите удалить.

3. Нажмите кнопку «Удалить» в верхней части страницы.

4. На странице «Удалить учетные данные» выберите «Удалить» .

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

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

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

Перед изменением ключа API :

• Сначала попробуйте ограничить доступ к своим API-ключам, как описано в разделе «Ограничение доступа к API-ключам» .

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

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

1. Откройте страницу «Учетные данные платформы Google Maps» в консоли Google Cloud.

2. Откройте API-ключ, который хотите поменять местами.

3. В верхней части страницы выберите кнопку «Поворот» .

4. При желании можно изменить имя ключа API.

5. Выберите «Создать» .

6. Обновите свои приложения, чтобы использовать новый ключ.

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

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

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

1. Определите, каким приложениям нужны новые ключи :

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

2. Создайте и ограничьте новые ключи : добавьте ограничение для приложения и как минимум одно ограничение для API. Для получения дополнительной информации см. раздел «Рекомендуемые лучшие практики» .

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

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

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

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

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

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

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

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

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

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

Использование клиентских SDK также позволит вам внедрить более продвинутые механизмы безопасности, такие как Firebase App Check на тех платформах API, которые его поддерживают. Дополнительные сведения см. в разделе «Использование 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 Maps Platform.

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

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

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

Защитите свой секрет подписания

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

• Генерируйте подписанные URL-адреса запросов для статического API карт и статического API просмотра улиц на стороне сервера при отображении веб-страницы или в ответ на запрос из вашего мобильного приложения .

  Для статического веб-контента можно использовать виджет «Подписать URL сейчас» на странице «Учетные данные платформы Google Maps» в консоли Cloud Console.

  Для динамического веб-контента ознакомьтесь с доступными примерами кода для подписи URL-запросов.

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

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

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

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

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

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

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

Хотя протокол OAuth 2.0 поддерживает сценарии использования, когда конечный пользователь разрешает приложению получать доступ к персональным данным от его имени, предполагаемый сценарий использования OAuth 2.0 с Maps Platform заключается в том, чтобы разработчик использовал временные токены доступа для авторизации своего приложения на вызов API от имени учетной записи сервиса проекта Google Cloud с разрешениями этой учетной записи.

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

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

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

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

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

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

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

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

Основные моменты:

• Формируйте запросы к платформе Google Maps на прокси-сервере. Не позволяйте клиентам перенаправлять произвольные вызовы API через прокси.

• Обработайте ответы платформы Google Maps на своем прокси-сервере. Отфильтруйте данные, которые клиенту не нужны.

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

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

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

1. Используйте HTTP-заголовки:

   • Android : Используйте HTTP-заголовки X-Android-Package и X-Android-Cert .

   • iOS : Используйте HTTP-заголовок X-Ios-Bundle-Identifier .

2. Добавьте соответствующие ограничения для приложений к вашему ключу Android или iOS.

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

   Если ограничения для приложений Android и iOS не поддерживаются на тестируемом устройстве, Google настоятельно рекомендует использовать защищенный прокси-сервер между мобильными клиентами и веб-сервисом Google Maps Platform.

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

• Прежде чем интегрировать ваше Android-приложение с сервисами платформы Google Maps, убедитесь, что идентификатор приложения (также называемый именем пакета) отформатирован правильно. Подробности см. в разделе «Настройка модуля приложения » в документации Android.

• Чтобы передать X-Android-Package напрямую из вашего приложения, найдите его программно, используя Context.getPackageName() .

• Для прямой передачи X-Android-Cert из ваших приложений вычислите необходимый отпечаток SHA-1 сертификатов подписи вашего приложения, доступный через PackageInfo.signingInfo .

• Если вы авторизуете свое Android-приложение с помощью консоли Google Cloud, обратите внимание, что пользовательский интерфейс ожидает, что отпечаток SHA-1 будет представлять собой строку, разделенную двоеточиями, например, 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33 . Однако инструмент gcloud и API-ключи ожидают шестнадцатеричную строку без разделителей.

Советы по разработке iOS-приложений:

• Прежде чем интегрировать ваше iOS-приложение с сервисами платформы Google Maps, убедитесь, что ваш идентификатор пакета (Bundle ID) отформатирован правильно .

• Как правило, при авторизации iOS-приложения в заголовке X-Ios-Bundle-Identifier следует всегда передавать идентификатор основного пакета (Bundle ID).

Для получения дополнительной информации обратитесь к статьям «Управление ключами API» и «Использование ключей API для доступа к API» .

Размещайте свои браузерные приложения на сервере.

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

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

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

Используйте App Check для защиты вашего API-ключа.

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

Инструкции по интеграции с App Check:

• Places SDK для iOS
• Places SDK для Android
• API карт на JavaScript
• Класс Place, API JavaScript для работы с картами

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

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

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

   • Ограничьте использование ваших API-ключей
   • Переход на использование нескольких ключей API
   • Используйте отдельные API-ключи для каждого приложения.

2. Если вы используете Places SDK или Maps Javascript API, вы также можете использовать App Check для защиты своего ключа API .

3. Заменять или поворачивать ключи следует только в том случае, если выполняется следующее условие:

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

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

   Прежде чем продолжить, ознакомьтесь с разделом «Будьте осторожны при смене ключей API» .

4. Если у вас по-прежнему возникают проблемы или вам нужна помощь, обратитесь в службу поддержки .

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

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

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

Следующие правила, касающиеся ограничений API, применяются ко всем сервисам платформы Google Maps:

• Используйте свой API-ключ только для тех API, для которых вы его применяете, за исключением следующих случаев:

  • Если ваше приложение использует Places SDK для Android или Places SDK для iOS, авторизуйте Places API (новый) или Places API в зависимости от используемой версии SDK. ¹

  • Если ваше приложение использует Maps JavaScript API, всегда авторизуйте его с помощью ключа.

  • Если вы также используете какие-либо из следующих сервисов Maps JavaScript API, вам следует авторизовать соответствующие API:

    Услуга	ограничение API
    Служба навигации (устаревшая)	API для построения маршрутов (устаревшая версия)
    Сервис Distance Matrix (устаревшая версия)	API матрицы расстояний (устаревшая версия)
    Служба лифтов	API для определения высоты
    Сервис геокодирования	API геокодирования
    Класс Place, виджет автозаполнения Place (новый) и API данных автозаполнения Place	API для работы с местами (новый) 2
    Библиотека мест, Сервис мест и Виджет автозаполнения мест	Places API 2

^1. Более подробную информацию см. в документации Places SDK для Android и Places SDK для iOS .

^2. Если вы не уверены, нужно ли авторизовать Places API (новый) или Places API, обратитесь к документации по Maps JavaScript API .

Несколько примеров:

• Вы используете Maps SDK для Android и Places SDK для Android, поэтому в качестве ограничений API следует включить Maps SDK для Android и Places API (новый).

• Ваш веб-сайт использует сервис отображения высот Maps JavaScript API и статический API Maps, поэтому вам необходимо добавить ограничения для всех следующих API:

  • API карт на JavaScript
  • API для определения высоты
  • Статический API карт

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

Веб-сайты

Для веб-сайтов, использующих сервисы Maps JavaScript API, Maps Static API или Street View Static API, а также для прямого вызова последних сервисов платформы Google Maps через HTTPS REST API или gRPC, используйте ограничение для веб- приложений:

Служба навигации (устаревшая) Сервис Distance Matrix (устаревшая версия) Служба лифтов Сервис геокодирования

Карты JavaScript API 1 Библиотека Places 2 Статический API карт 3 Статический API 3 для просмотра улиц

^1. Для мобильных приложений рекомендуется использовать нативные Maps SDK для Android и Maps SDK для iOS .

^2. Для мобильных приложений рекомендуется использовать нативные SDK Places для Android и Places SDK для iOS .

³ См. также раздел «Защита использования статического веб-API» .

Веб-сайты с API для встраивания карт

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

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

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

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

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

Используйте для приложений и серверов, использующих следующие API:

API проверки адресов API для просмотра с воздуха API качества воздуха API для построения маршрутов (устаревшая версия) 4 API матрицы расстояний (устаревшая версия) 4 API для определения высоты API геокодирования 5 API геолокации 6 API картографических тайлов

API наборов данных карт API для работы с местами (новый) 7 Places API 6 API дорог Routes API 4 Pollen API Солнечный API Time Zone API 8 API погоды

⁴ For mobile applications, consider using the Navigation SDK.

^5. Для безопасного использования мобильных устройств используйте защищенный прокси-сервер .

^6. Для клиентских приложений рекомендуется использовать встроенную службу геолокации, предоставляемую платформой; например, W3C Geolocation для веб-браузеров, LocationManager или Fused Location Provider API для Android, или фреймворк Apple Core Location для iOS.

^7. Для мобильных приложений рекомендуется использовать нативные SDK Places для Android и Places SDK для iOS .

^8. Для безопасного использования на стороне клиента используйте защищенный прокси-сервер .

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

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

• SDK для карт для Android
• Places SDK for Android
• SDK для навигации для Android

Кроме того, чтобы избежать случайной добавления ключей API в систему контроля версий, используйте плагин Secrets Gradle для внедрения секретов из локального файла, а не для их хранения в Android Manifest.

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

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

• SDK для работы с картами на iOS
• Places SDK для iOS
• SDK для навигации в iOS

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

• Управление ключами API
• Используйте ключи API для доступа к API.
• Оптимизируйте использование платформы Google Maps с помощью квот (видео)
• Как генерировать и ограничивать доступ к API-ключам для платформы Google Maps (видео)
• Ограничение доступа к ключам API
• Защита ключей API при использовании API статических карт и просмотра улиц.
• 15 лучших практик использования платформы Google Maps

,

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

Эти рекомендации помогут вам обеспечить безопасность доступа к платформе карт.

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

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

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

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

Рекомендуемые передовые методы

Для повышения безопасности и во избежание выставления счетов за несанкционированное использование, следуйте этим рекомендациям по обеспечению безопасности API для всех API, SDK и сервисов платформы Google Maps:

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

Ограничьте использование ваших API-ключей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Дополнительные инструкции см. в разделе «Переход на использование нескольких ключей API» .

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

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

  Для получения дополнительной информации см. раздел «Обработка несанкционированного использования ключа API» .

Более подробная информация

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

Ограничьте использование ваших API-ключей

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

• Ограничения для приложений. Вы можете ограничить использование ключа API определенными платформами: приложениями Android или iOS, определенными веб-сайтами для клиентских приложений или определенными IP-адресами или подсетями CIDR для серверных приложений, выполняющих вызовы REST API веб-сервисов.

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

• Ограничения API. Вы можете ограничить использование вашего ключа API для определенных API, SDK или сервисов платформы Google Maps. Ограничения API разрешают запросы только к указанным вами API и SDK. Для каждого ключа API можно указать столько ограничений, сколько необходимо. Список доступных API включает все API, включенные в проекте.

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

1. Откройте страницу «Учетные данные платформы Google Maps» в консоли Google Cloud.

2. Выберите ключ API, доступ к которому вы хотите ограничить.

3. На странице редактирования ключа API в разделе «Ограничения ключа» выберите «Установить ограничение для приложения» .

   

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

   Restriction type	Описание
   Веб-сайты	Укажите один или несколько сайтов-источников перехода. The universally supported referrer URI schemes are https and http . 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 the whole referrer string, including the protocol scheme, hostname and optional port (eg, 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-адреса	Укажите один или несколько IPv4 или IPv6 адресов, либо подсетей, используя нотацию CIDR. IP-адреса должны совпадать с исходным адресом, который наблюдают серверы платформы Google Maps. Если вы используете трансляцию сетевых адресов (NAT) , этот адрес обычно соответствует публичному IP-адресу вашего компьютера.
   Приложения для Android	Add the Android package name (from the AndroidManifest.xml file) and the SHA-1 signing certificate fingerprint of each Android application you want to authorize. Выберите приложения для Android . Нажмите + Добавить . Введите имя пакета и отпечаток сертификата SHA-1. Например: com.example.android.mapexample BB:0D:AC:74:D3:21:E1:43:67:71:9B:62:91:AF:A1:66:6E:44:5D:75 Нажмите « Сохранить ». Существует два типа сертификатов: Отладочный сертификат : Используйте этот тип сертификата только для тестируемых приложений и другого кода, не предназначенного для производственной среды. Не пытайтесь опубликовать приложение, подписанное отладочным сертификатом. Инструменты Android SDK автоматически генерируют этот сертификат при запуске отладочной сборки. Сертификат для выпуска : Используйте этот сертификат, когда будете готовы выпустить свое приложение в магазин приложений. Инструменты Android SDK генерируют этот сертификат при запуске сборки для выпуска. Для получения дополнительной информации о подписании приложений Android и сертификатах см. руководство «Подпишите свое приложение» . Если вы используете функцию подписи приложений Play , чтобы получить отпечаток сертификата подписи, см. раздел «Работа с поставщиками API» . Если вы управляете собственным ключом подписи, см. раздел «Самоподписание приложения» или обратитесь к инструкциям для вашей среды сборки.
   приложения для iOS	Добавьте идентификатор пакета каждого iOS-приложения, которое вы хотите авторизовать. Выберите приложения для iOS . Нажмите + Добавить . Добавьте идентификатор пакета, чтобы принимать запросы от iOS-приложения с этим идентификатором. Нажмите « Сохранить ».

   Рекомендации по ограничению использования приложения см. в разделе «Рекомендуемые ограничения использования приложения» .

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

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

1. Откройте страницу «Учетные данные платформы Google Maps» в консоли Google Cloud.

2. Выберите ключ API, доступ к которому вы хотите ограничить.

3. На странице редактирования ключа API , в разделе «Ограничения API» :

   • Выберите «Ограничить ключ» .

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

   Если API или SDK не указаны в списке, их необходимо включить. Подробнее см. раздел «Включение одного или нескольких API или SDK» .

   

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

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

For recommended API restrictions, see Recommended API Restrictions .

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

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

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

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

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

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

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

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

1. Перейдите в раздел «Обозреватель метрик» в консоли Google Cloud.

2. Войдите в систему и выберите проект, для которого хотите проверить ключи API.

3. Перейдите на страницу обозревателя метрик для вашего типа API:

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

   • Для получения ключей API, используемых с Maps Embed API , перейдите в раздел «Обозреватель метрик» .

4. Проверьте каждый ключ API:

   1. Выберите «ДОБАВИТЬ ФИЛЬТР» .

   2. Select the label credential_id .

   3. Выберите значение , соответствующее ключу, который вы хотите проверить.

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

   5. Once done, select Remove filter delete at the end of the active filter line to delete the extra filter.

5. Повторите то же самое для всех оставшихся ключей.

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

7. If you spot unauthorized use, see Handle unauthorized use of an API key .

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

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

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

If your API key doesn't have restriction recommendations, determine the type of application restriction to apply, based on the reported platform_type using the Metrics explorer:

1. Перейдите в раздел «Обозреватель метрик» в консоли Google Cloud.

2. Войдите в систему и выберите проект, для которого хотите проверить API.

3. Перейдите на эту страницу обозревателя метрик: Обозреватель метрик .

4. Проверьте каждый ключ API:

   1. Выберите «ДОБАВИТЬ ФИЛЬТР» .

   2. Select the label credential_id .

   3. Выберите значение , соответствующее ключу, который вы хотите проверить.

   4. Once done, select Remove filter delete at the end of the active filter line to delete the extra filter.

5. Повторите то же самое для всех оставшихся ключей.

6. Once you have the platform type for your API keys, apply the application restriction for that platform_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 : You may have to rely on IP address restrictions on the key, to properly restrict it.

   Рекомендации по использованию статического API карт и статического API просмотра улиц см. в разделе «Защита использования статического веб-API» .

   Рекомендации по использованию API для встраивания карт см. в разделе «Веб-сайты, использующие API для встраивания карт» .

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

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

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

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

Примените рекомендуемые ограничения на использование API-ключей.

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

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

Google Maps Platform APIs and SDKs supported by the automated recommendations

• Maps JavaScript API, including Directions Service (Legacy), Distance Matrix Service (Legacy), Elevation Service, Geocoding Service Place class, Place Autocomplete Widget (New), Place Autocomplete Data API, Places Library, Places Service, Place Autocomplete Widget, and Places UI Kit

• Maps Static API and Street View Static API

• 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, and Places UI Kit on iOS.

Reasons you may not see a recommendation, or an incomplete one

Reasons for seeing no recommendation

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

  If you see usage on other services, don't apply the recommendation without first doing the following:

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

  2. Manually add missing services to the list of APIs to be authorized.

  3. Manually add any missing application restrictions for the services added to the API list. If your other added would require a different type of application restrictions, see Migrate to multiple API keys .

• 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 usage over the last 60 days.

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

• You are using the API key in multiple applications that would require conflicting types of application restrictions, or you are using the same API key in too many different apps or websites. In either case, as a best practice, you should migrate to multiple keys. For more details, see Migrate 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 usage over the last 60 days.

• You have very recently started using a existing key on a new API or service, and the automatic API key restriction recommendation pipeline, has not yet processed the updated usage metrics. The propagation of usage metrics may take a few days.

  If you see usage on other services, don't apply the recommendation without first doing the following:

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

  2. Manually add missing services to the list of APIs to be authorized.

  3. Manually add any missing application restrictions for the services added to the API list. If your other added would require a different type of application restrictions, see Migrate to multiple API keys .

  4. Unless you urgently need to restrict a key, for example, due to unauthorized use, you might also wait a day or two for the recommendations to catch up.

Reasons you might see recommendations that are not visible in the charts

• Your app or website sent only very short traffic bursts. In this case, switch from a CHART view to display a TABLE or BOTH , as the usage is still visible in the legend. For more information, see Toggling the chart's full legends .

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

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

To apply recommended restrictions

1. Откройте страницу «Учетные данные платформы Google Maps» в консоли Google Cloud.

2. If available, select Apply recommended restrictions .

   

3. Select Check API usage to verify which services the API key is being used on. If you see other than Google Maps Platform services, pause to manually review the recommendation steps above. See the troubleshooting steps at the beginning of section Apply recommended API key restrictions .

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

5. Выберите «Применить» .

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.

Tips for 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:

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

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

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 .

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

1. Откройте страницу «Учетные данные платформы Google Maps» в консоли Google Cloud.

2. Select the API key you want to delete.

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

4. On the Delete credential page, select Delete .

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

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

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:

1. Откройте страницу «Учетные данные платформы Google Maps» в консоли Google Cloud.

2. Open the API key you want to rotate.

3. At the top of the page, select Rotate key .

4. Optionally, change the API key name.

5. Выберите «Создать» .

6. 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:

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 apps before the new keys can be used.

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

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

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

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 to make sure all end users get their fair share 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 per-user quota limit, or no limit at all.

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

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.

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

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 .

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

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 .

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

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

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.

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

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 .

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

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:

1. Use HTTP headers:

   • Android : Use the X-Android-Package and X-Android-Cert HTTP headers.

   • iOS : Use the X-Ios-Bundle-Identifier HTTP header.

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

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

• 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:

• Places SDK для iOS
• Places SDK for Android
• API карт на JavaScript
• Place class, Maps JavaScript API

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:

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. For more details, see:

   • Ограничьте использование ваших API-ключей
   • Migrate to multiple API keys
   • Используйте отдельные API-ключи для каждого приложения.

2. If you use the Places SDK or the Maps Javascript API, you can also use 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 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 .

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

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

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 the Places SDK for Android or Places SDK for iOS, authorize Places API (New) or Places API, depending on the SDK versions you use. ¹

  • 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 для определения высоты
    Сервис геокодирования	API геокодирования
    Place class, Place Autocomplete Widget (New) & Place Autocomplete Data API	Places API (New) 2
    Places Library, Places Service & Place Autocomplete Widget	Places API 2

¹ 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 для определения высоты
  • Maps Static 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:

Directions Service (Legacy) Distance Matrix Service (Legacy) Elevation Service Сервис геокодирования

Maps JavaScript API 1 Places Library 2 Maps Static API 3 Street View Static API 3

¹ 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:

API проверки адресов API для просмотра с воздуха API качества воздуха Directions API (Legacy) 4 Distance Matrix API (Legacy) 4 API для определения высоты Geocoding API 5 Geolocation API 6 Map Tiles API

Maps Datasets API Places API (New) 7 Places API 6 API дорог Routes API 4 Pollen API Солнечный API Time Zone API 8 API погоды

⁴ For mobile applications, consider using the Navigation SDK.

^5. Для безопасного использования мобильных устройств используйте защищенный прокси-сервер .

^6. Для клиентских приложений рекомендуется использовать встроенную службу геолокации, предоставляемую платформой; например, W3C Geolocation для веб-браузеров, LocationManager или Fused Location Provider API для Android, или фреймворк Apple Core Location для iOS.

^7. Для мобильных приложений рекомендуется использовать нативные SDK Places для Android и Places SDK для iOS .

^8. Для безопасного использования на стороне клиента используйте защищенный прокси-сервер .

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

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

• SDK для карт для Android
• Places SDK for Android
• SDK для навигации для Android

Кроме того, чтобы избежать случайной добавления ключей API в систему контроля версий, используйте плагин Secrets Gradle для внедрения секретов из локального файла, а не для их хранения в Android Manifest.

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

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

• SDK для работы с картами на iOS
• Places SDK для iOS
• SDK для навигации в iOS

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

• Управление ключами API
• Используйте ключи API для доступа к API.
• Оптимизируйте использование платформы Google Maps с помощью квот (видео)
• Как генерировать и ограничивать доступ к API-ключам для платформы Google Maps (видео)
• Ограничение доступа к ключам API
• Защита ключей API при использовании API статических карт и просмотра улиц.
• 15 лучших практик использования платформы Google Maps