Дополнительные меры, необходимые для выполнения линейных действий
Для защиты встроенных действий требуются или приветствуются дополнительные меры безопасности:
HTTPS : все действия должны выполняться через URL-адреса HTTPS. На хостах должны быть установлены действительные SSL-сертификаты сервера.
Токены доступа : отправителям, использующим действия, рекомендуется встраивать токены доступа с ограниченным использованием в URL-адреса действий для защиты от атак повторного воспроизведения . Это, как правило, хорошая практика для любых URL-адресов, встроенных в веб-страницы или электронные письма, которые могут вызывать побочные эффекты при вызове.
Авторизация носителя : сервисам, обрабатывающим запросы на действия, рекомендуется проверять заголовок HTTP «Authorization» в HTTPS-запросе. Этот заголовок будет содержать строку «Bearer Token», подтверждающую, что источником запроса является google.com и что запрос предназначен для указанного сервиса. Сервисы должны использовать библиотеку с открытым исходным кодом, предоставленную Google, для проверки токена носителя .
Обеспечение безопасности шаблонов доступа к электронной почте в крайних случаях
Gmail обрабатывает различные варианты пересылки и шаблонов доступа для обеспечения безопасности действий в электронных письмах. В дополнение к вышеперечисленным мерам выполняются следующие действия:
Шаблон доступа
Дополнительные меры безопасности
Ручная пересылка — пользователь открывает электронное письмо и пересылает его нескольким получателям.
Такая пересылка всегда нарушает DKIM-подписи, и отправитель больше не регистрируется в сервисе. Действия в письме отклоняются .
Автоматическая пересылка на Gmail . Пользователь создает правило пересылки для почтового ящика user@acme.com на свой почтовый ящик Gmail.
Gmail проверяет, может ли пользователь отправлять сообщения с адреса user@acme.com (пользователь настраивает это вручную). Действия в письме принимаются .
Извлечение писем Gmail по протоколу POP . Пользователь вводит Gmail пароль для user@acme.com, и Gmail извлекает все письма с этого адреса по протоколу POP в почтовый ящик Gmail.
Подписи DKIM и целостность контента сохранены. У пользователя есть подтверждённый доступ к user@acme.com. Действия, указанные в письме, принимаются .
Доступ к электронной почте Gmail с помощью сторонних приложений . Пользователь Gmail использует стороннее приложение (например, Outlook или Thunderbird) для доступа к электронной почте Gmail или пересылает свои письма Gmail другому провайдеру электронной почты.
Сторонние приложения или сервисы могут использовать встроенную информацию. Однако они не смогут создавать токены аутентификации на предъявителя, соответствующие токенам Google, что даст отправителям возможность отклонять такие запросы на действия. Отправители могут выбирать, отклонять или принимать действия без токенов на предъявителя, в зависимости от степени конфиденциальности действия. Обратите внимание, что токен авторизации на предъявителя создается с использованием стандартных технологий с открытым исходным кодом, что позволяет всем почтовым сервисам и приложениям создавать их с использованием собственных ключей.
[null,null,["Последнее обновление: 2025-08-29 UTC."],[],[],null,["# Securing Actions\n\nThis page document how Gmail secures the delivery and execution of actions.\n\nSecurity Measures enforced by Google\n------------------------------------\n\nThe following conditions must hold for schemas embedded in email:\n\n- **Registration** : Sender must [Register with Google](../registering-with-google).\n- **SPF** or **DKIM** : Emails with schema markup **must** arrive from [SPF or DKIM authenticated domains](https://support.google.com/mail/answer/180707)\n\nAdditional Measures required for In-Line Actions\n------------------------------------------------\n\nExtra security measures are required or encouraged to secure inline actions:\n\n- **HTTPS** : All actions **must** be handled via HTTPS URLs. Hosts must have valid SSL server certificates installed.\n- **Access Tokens** : It is **encouraged** that senders using actions embed [Limited-Use Access Tokens](/workspace/gmail/markup/actions/limited-use-access-tokens) in the action URLs, to protected themselves against [Replay Attacks](http://en.wikipedia.org/wiki/Replay_attack). This is a generally good practice for any URL embedded in webpages or emails that might have any side-effects when invoked.\n- **Bearer Authorization** : It is **encouraged** that services handling action requests verify the Http \"Authorization\" header in the HTTPS request. That header will contain a \"Bearer Token\" string, proving that the source of the request is google.com, and that the request is intended for the specified service. Services should use the Google-provided open source library to [Verify the Bearer Token](/workspace/gmail/markup/actions/verifying-bearer-tokens).\n\n| **Note:** Bearer tokens in authorization headers are not sent by default. If you require a bearer token token to be sent, request it when [registering with Google](/workspace/gmail/markup/registering-with-google).\n\nSecuring Edge-Case Email Access Patterns\n----------------------------------------\n\nThere are various variants of email forwarding and access patterns that Gmail handles in order to secure actions in emails. These following measurements are performed **IN ADDITION** to the measures above:\n\n| Access Pattern | Additional Security Measures |\n|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| **Manual Forwarding** - User opens an email and forwards it to more recipients | Such forwarding always breaks DKIM signatures, and the sender is no longer registered with the service. Actions in the email are **rejected**. |\n| **Auto Forwarding to Gmail** - User creates a forwarding rule on mailbox user@acme.com to her gmail mailbox. | Gmail verifies that the user can send as user@acme.com (user sets this up manually). Actions in the email are **accepted**. |\n| **Gmail POP fetching** - User gives Gmail the password for user@acme.com and Gmail fetchers all emails there via POP to the Gmail inbox. | DKIM signatures and content integrity is preserved. User has proven access to user@acme.com. Actions in the email are **accepted**. |\n| **Accessing Gmail emails with 3rd party applications** - Gmail user uses a 3rd party application (e.g. Outlook or Thunderbird) to access Gmail emails, or forwards her Gmail emails to another email provider. | 3rd party application or service may use embedded information. However, it won't be able to produce bearer authentication tokens that match Google's, giving senders the opportunity to reject such action requests. Senders may choose whether they reject or accept actions without bearer tokens, depending on the sensitivity of the action. Note that the bearer authorization token is created using standard open source technologies making it possible to all mail providers and apps to produce them using their own keys. |"]]
