Medidas adicionais necessárias para ações em linha
Medidas extras de segurança são necessárias ou recomendadas para proteger as ações inline:
HTTPS: todas as ações precisam ser processadas por URLs HTTPS. Os hosts precisam ter certificados de servidor SSL válidos instalados.
Tokens de acesso: recomenda-se que os remetentes que usam ações incorporem tokens de acesso de uso limitado nos URLs de ação para se protegerem contra ataques de repetição. Essa é uma prática recomendada para qualquer URL incorporado em páginas da Web ou e-mails que possam ter efeitos colaterais quando invocados.
Autorização do portador: é recomendado que os serviços que processam solicitações de ação verifiquem o cabeçalho HTTP "Authorization" na solicitação HTTPS. Esse cabeçalho vai conter uma string "Bearer Token", provando que a origem da solicitação é google.com e que ela se destina ao serviço especificado. Os serviços precisam usar a biblioteca de código aberto fornecida pelo Google para verificar o token do portador.
Proteção de padrões de acesso de e-mail de casos extremos
Há várias variantes de encaminhamento de e-mail e padrões de acesso que o Gmail processa para proteger ações em e-mails. As seguintes medições são realizadas ALÉM das medidas acima:
Padrão de acesso
Medidas de segurança adicionais
Encaminhamento manual: o usuário abre um e-mail e encaminha para mais destinatários.
Esse encaminhamento sempre quebra as assinaturas DKIM, e o remetente não está mais registrado no serviço. As ações no e-mail são rejeitadas.
Encaminhamento automático para o Gmail: o usuário cria uma regra de encaminhamento na caixa de e-mail user@acme.com para a caixa de e-mail do Gmail dele.
O Gmail verifica se o usuário pode enviar como user@acme.com (o usuário configura isso manualmente). As ações no e-mail são aceitas.
Busca POP do Gmail: o usuário informa a senha de user@acme.com ao Gmail, que busca todos os e-mails via POP para a caixa de entrada do Gmail.
As assinaturas DKIM e a integridade do conteúdo são preservadas. O usuário tem acesso comprovado a user@acme.com. As ações no e-mail são aceitas.
Acessar e-mails do Gmail com aplicativos de terceiros: um usuário do Gmail usa um aplicativo de terceiros (por exemplo, Outlook ou Thunderbird) para acessar e-mails do Gmail ou encaminha os e-mails do Gmail para outro provedor de e-mail.
Um aplicativo ou serviço de terceiros pode usar informações incorporadas. No entanto, ele não poderá produzir tokens de autenticação de portador que correspondam aos do Google, aos remetentes a oportunidade de rejeitar essas solicitações de ação. Os remetentes podem escolher se rejeitam ou aceitam ações sem tokens de portador, dependendo da sensibilidade da ação. O token de autorização do portador é criado usando tecnologias padrão de código aberto, o que permite que todos os provedores de e-mail e apps produzam tokens usando as próprias chaves.
[null,null,["Última atualização 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. |"]]
