Zusätzliche Maßnahmen für Inline-Aktionen erforderlich
Für Inlineaktionen sind zusätzliche Sicherheitsmaßnahmen erforderlich oder werden empfohlen:
HTTPS: Alle Aktionen müssen über HTTPS-URLs abgewickelt werden. Auf Hosts müssen gültige SSL-Serverzertifikate installiert sein.
Zugriffstokens: Absender, die Aktionen verwenden, sollten Zugriffstokens mit eingeschränkter Nutzung in die Aktions-URLs einbetten, um sich vor Replay-Angriffen zu schützen. Das ist generell eine gute Vorgehensweise für alle URLs, die in Webseiten oder E-Mails eingebettet sind und bei Aufruf Nebenwirkungen haben könnten.
Bearer Authorization: Es wird empfohlen, dass Dienste, die Aktionsanfragen verarbeiten, den HTTP-Header „Authorization“ in der HTTPS-Anfrage überprüfen. Dieser Header enthält einen „Bearer Token“-String, der beweist, dass die Quelle der Anfrage google.com ist und dass die Anfrage für den angegebenen Dienst bestimmt ist. Dienste sollten die von Google bereitgestellte Open-Source-Bibliothek verwenden, um das Inhabertoken zu überprüfen.
Sichern von Edge-Case-E-Mail-Zugriffsmustern
Gmail unterstützt verschiedene Varianten der E‑Mail-Weiterleitung und Zugriffsmuster, um Aktionen in E‑Mails zu schützen. Die folgenden Messungen werden ZUSÄTZLICH zu den oben genannten Maßnahmen durchgeführt:
Zugriffsmuster
Zusätzliche Sicherheitsmaßnahmen
Manuelle Weiterleitung: Der Nutzer öffnet eine E-Mail und leitet sie an weitere Empfänger weiter.
Bei dieser Art der Weiterleitung kommt es immer zu Fehlern bei den Signaturen von DomainKeys Identified Mails und der Absender ist nicht mehr beim Dienst registriert. Aktionen in der E‑Mail werden abgelehnt.
Automatische Weiterleitung an Gmail: Der Nutzer erstellt eine Weiterleitungsregel für das Postfach user@acme.com an sein Gmail-Postfach.
Gmail prüft, ob der Nutzer E-Mails als „nutzer@beispiel.de“ senden kann (der Nutzer richtet dies manuell ein). Aktionen in der E‑Mail werden akzeptiert.
Gmail-POP-Abruf: Der Nutzer gibt das Passwort für nutzer@beispiel.de an Gmail weiter und Gmail ruft alle E-Mails über POP in den Gmail-Posteingang ab.
DKIM-Signaturen und die Inhaltsintegrität bleiben erhalten. Der Nutzer hat den Zugriff auf user@acme.com nachgewiesen. Aktionen in der E-Mail werden akzeptiert.
Auf Gmail-E‑Mails mit Drittanbieteranwendungen zugreifen: Ein Gmail-Nutzer greift mit einer Drittanbieteranwendung (z.B. Outlook oder Thunderbird) auf Gmail-E‑Mails zu oder leitet seine Gmail-E‑Mails an einen anderen E‑Mail-Anbieter weiter.
Drittanbieter-Apps oder ‑Dienste können eingebettete Informationen verwenden. Es kann jedoch keine Bearer-Authentifizierungstokens erstellen, die mit denen von Google übereinstimmen. Absender haben daher die Möglichkeit, solche Aktionsanfragen abzulehnen. Absender können je nach Sensibilität der Aktion entscheiden, ob sie Aktionen ohne Bearer-Tokens ablehnen oder akzeptieren. Das Bearer-Autorisierungstoken wird mit standardmäßigen Open-Source-Technologien erstellt. Daher können alle E-Mail-Anbieter und Apps es mit ihren eigenen Schlüsseln erstellen.
[null,null,["Zuletzt aktualisiert: 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. |"]]
