Dodatkowe środki wymagane w przypadku działań w tekście
Aby zabezpieczyć działania wbudowane, wymagane lub zalecane są dodatkowe środki bezpieczeństwa:
HTTPS: wszystkie działania muszą być obsługiwane za pomocą adresów URL HTTPS. Na hostach muszą być zainstalowane prawidłowe certyfikaty serwera SSL.
Tokeny dostępu: zaleca się, aby nadawcy korzystający z działań osadzali w adresach URL działań tokeny dostępu do ograniczonego użytku, aby chronić się przed atakami typu replay. Jest to ogólnie dobra praktyka w przypadku każdego adresu URL osadzonego na stronach internetowych lub w e-mailach, którego wywołanie może mieć skutki uboczne.
Autoryzacja za pomocą tokena: zaleca się, aby usługi obsługujące żądania działań weryfikowały nagłówek HTTP „Authorization” w żądaniu HTTPS. Ten nagłówek będzie zawierać ciąg znaków „Bearer Token”, który potwierdza, że źródłem żądania jest google.com i że żądanie jest przeznaczone dla określonej usługi. Usługi powinny używać udostępnionej przez Google biblioteki open source do weryfikowania tokena okaziciela.
Zabezpieczanie nietypowych wzorców dostępu do poczty e-mail
Gmail obsługuje różne warianty przekazywania e-maili i wzorce dostępu, aby zabezpieczyć działania w e-mailach. Oprócz powyższych pomiarów wykonujemy DODATKOWO te pomiary:
Wzorzec dostępu
Dodatkowe środki bezpieczeństwa
Ręczne przekazywanie dalej – użytkownik otwiera e-maila i przekazuje go dalej do większej liczby odbiorców.
Takie przekazywanie zawsze narusza podpisy DKIM, a nadawca nie jest już zarejestrowany w usłudze. Działania w e-mailu są odrzucane.
Automatyczne przekazywanie dalej do Gmaila – użytkownik tworzy regułę przekazywania dalej w skrzynce pocztowej user@acme.com do swojej skrzynki pocztowej Gmail.
Gmail sprawdza, czy użytkownik może wysyłać e-maile jako użytkownik@acme.com (użytkownik konfiguruje to ręcznie). Działania w e-mailu są akceptowane.
Pobieranie poczty z Gmaila za pomocą POP – użytkownik podaje Gmailowi hasło do konta użytkownik@acme.com, a Gmail pobiera wszystkie e-maile z tego konta za pomocą POP do skrzynki odbiorczej Gmaila.
Podpisy DKIM i integralność treści są zachowywane. Użytkownik ma potwierdzony dostęp do adresu user@acme.com. Działania w e-mailu są akceptowane.
Dostęp do e-maili w Gmailu za pomocą aplikacji innych firm – użytkownik Gmaila korzysta z aplikacji innej firmy (np. Outlooka lub Thunderbirda), aby uzyskać dostęp do e-maili w Gmailu, lub przekazuje e-maile z Gmaila do innego dostawcy poczty e-mail.
Aplikacja lub usługa innej firmy może używać informacji osadzonych. Nie będzie jednak w stanie generować tokenów uwierzytelniania za pomocą tokena dostępu, które pasują do tokenów Google, co umożliwi nadawcom odrzucanie takich żądań działania. Nadawcy mogą odrzucać lub akceptować działania bez tokenów dostępu w zależności od tego, jak wrażliwe są te działania. Pamiętaj, że token autoryzacji typu bearer jest tworzony przy użyciu standardowych technologii open source, dzięki czemu wszyscy dostawcy poczty i aplikacje mogą go generować za pomocą własnych kluczy.
[null,null,["Ostatnia aktualizacja: 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. |"]]
