Medidas adicionales requeridas para las acciones intercaladas
Se requieren o recomiendan medidas de seguridad adicionales para proteger las acciones intercaladas:
HTTPS: Todas las acciones deben controlarse a través de URLs HTTPS. Los hosts deben tener instalados certificados de servidor SSL válidos.
Tokens de acceso: Se recomienda que los remitentes que usan acciones incorporen tokens de acceso de uso limitado en las URLs de acción para protegerse contra los ataques de repetición. Esta es una práctica recomendada para cualquier URL incorporada en páginas web o correos electrónicos que puedan tener efectos secundarios cuando se invoquen.
Autorización de portador: Se recomienda que los servicios que controlan solicitudes de acción verifiquen el encabezado "Authorization" de Http en la solicitud HTTPS. Ese encabezado contendrá una cadena de "token de portador", que demostrará que la fuente de la solicitud es google.com y que la solicitud está destinada al servicio especificado. Los servicios deben usar la biblioteca de código abierto proporcionada por Google para verificar el token del portador.
Protección de patrones de acceso de correo electrónico en casos extremos
Gmail controla varias variantes de reenvío de correos electrónicos y patrones de acceso para proteger las acciones en los correos electrónicos. Las siguientes mediciones se realizan ADEMÁS de las anteriores:
Patrón de acceso
Medidas de seguridad adicionales
Reenvío manual: El usuario abre un correo electrónico y lo reenvía a más destinatarios.
Este reenvío siempre interrumpe las firmas DKIM, y el remitente ya no está registrado en el servicio. Las acciones en el correo electrónico se rechazan.
Reenvío automático a Gmail: El usuario crea una regla de reenvío en el buzón de correo usuario@acme.com a su buzón de correo de Gmail.
Gmail verifica que el usuario pueda enviar correos electrónicos como usuario@acme.com (el usuario configura esto de forma manual). Las acciones en el correo electrónico se aceptan.
Recuperación de POP de Gmail: El usuario le proporciona a Gmail la contraseña de usuario@acme.com, y Gmail recupera todos los correos electrónicos a través de POP en la bandeja de entrada de Gmail.
Se conservan las firmas DKIM y la integridad del contenido. El usuario demostró tener acceso a user@acme.com. Las acciones en el correo electrónico se aceptan.
Acceso a correos electrónicos de Gmail con aplicaciones de terceros: El usuario de Gmail usa una aplicación de terceros (p.ej., Outlook o Thunderbird) para acceder a los correos electrónicos de Gmail o reenvía sus correos electrónicos de Gmail a otro proveedor de correo electrónico.
Es posible que la aplicación o el servicio de terceros usen información incorporada. Sin embargo, no podrá generar tokens de autenticación de portador que coincidan con los de Google, lo que les dará a los remitentes la oportunidad de rechazar esas solicitudes de acción. Los remitentes pueden elegir si rechazan o aceptan acciones sin tokens de portador, según la sensibilidad de la acción. Ten en cuenta que el token de autorización de portador se crea con tecnologías de código abierto estándar, lo que permite que todos los proveedores y las apps de correo electrónico los produzcan con sus propias claves.
[null,null,["Última actualización: 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. |"]]
