Mesures supplémentaires requises pour les actions intégrées
Des mesures de sécurité supplémentaires sont requises ou recommandées pour sécuriser les actions intégrées :
HTTPS : toutes les actions doivent être gérées via des URL HTTPS. Les hôtes doivent avoir installé des certificats de serveur SSL valides.
Jetons d'accès : il est recommandé aux expéditeurs qui utilisent des actions d'intégrer des jetons d'accès à usage limité dans les URL d'action pour se protéger contre les attaques par rejeu. Il s'agit d'une bonne pratique générale pour toute URL intégrée à des pages Web ou à des e-mails qui pourrait avoir des effets secondaires lorsqu'elle est appelée.
Autorisation du porteur : il est recommandé que les services qui traitent les requêtes d'action vérifient l'en-tête HTTP "Authorization" dans la requête HTTPS. Cet en-tête contiendra une chaîne "Bearer Token" (jeton du porteur), prouvant que la source de la requête est google.com et que la requête est destinée au service spécifié. Les services doivent utiliser la bibliothèque Open Source fournie par Google pour valider le jeton de support.
Sécuriser les modèles d'accès aux e-mails dans des cas extrêmes
Gmail gère différentes variantes de transfert d'e-mails et de modèles d'accès pour sécuriser les actions dans les e-mails. Les mesures suivantes sont effectuées EN PLUS de celles ci-dessus :
Modèle d'accès
Mesures de sécurité supplémentaires
Transfert manuel : l'utilisateur ouvre un e-mail et le transfère à d'autres destinataires.
Un tel transfert casse toujours les signatures DKIM, et l'expéditeur n'est plus enregistré auprès du service. Les actions dans l'e-mail sont refusées.
Transfert automatique vers Gmail : l'utilisateur crée une règle de transfert sur la boîte aux lettres user@acme.com vers sa boîte aux lettres Gmail.
Gmail vérifie que l'utilisateur peut envoyer des e-mails en tant que user@acme.com (l'utilisateur configure cette option manuellement). Les actions dans l'e-mail sont acceptées.
Récupération POP Gmail : l'utilisateur fournit à Gmail le mot de passe de user@acme.com, et Gmail récupère tous les e-mails via POP dans la boîte de réception Gmail.
Les signatures DKIM et l'intégrité du contenu sont conservées. L'utilisateur a prouvé qu'il avait accès à user@acme.com. Les actions dans l'e-mail sont acceptées.
Accéder aux e-mails Gmail avec des applications tierces : un utilisateur Gmail utilise une application tierce (Outlook ou Thunderbird, par exemple) pour accéder à ses e-mails Gmail ou les transfère vers un autre fournisseur de messagerie.
Une application ou un service tiers peut utiliser les informations intégrées. Toutefois, il ne pourra pas générer de jetons d'authentification du porteur correspondant à ceux de Google, ce qui permettra aux expéditeurs de refuser ces demandes d'action. Les expéditeurs peuvent choisir de refuser ou d'accepter les actions sans jetons porteurs, en fonction de la sensibilité de l'action. Notez que le jeton d'autorisation du porteur est créé à l'aide de technologies Open Source standards, ce qui permet à tous les fournisseurs et applications de messagerie de les produire à l'aide de leurs propres clés.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/29 (UTC).
[null,null,["Dernière mise à jour le 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. |"]]
