Tindakan Tambahan yang diperlukan untuk Tindakan Sebaris
Langkah-langkah keamanan tambahan diperlukan atau dianjurkan untuk mengamankan tindakan inline:
HTTPS: Semua tindakan harus ditangani melalui URL HTTPS. Host harus menginstal sertifikat server SSL yang valid.
Token Akses: Pengirim yang menggunakan tindakan dianjurkan untuk menyematkan Token Akses Penggunaan Terbatas di URL tindakan, untuk melindungi diri mereka dari Serangan Replay. Ini adalah praktik yang umumnya baik untuk URL apa pun yang disematkan di halaman web atau email yang mungkin memiliki efek samping saat dipanggil.
Otorisasi Bearer: Sebaiknya layanan yang menangani permintaan tindakan memverifikasi header "Authorization" HTTP dalam permintaan HTTPS. Header tersebut akan berisi string "Token Bearer", yang membuktikan bahwa sumber permintaan adalah google.com, dan permintaan tersebut ditujukan untuk layanan yang ditentukan. Layanan harus menggunakan library open source yang disediakan Google untuk Memverifikasi Token Bearer.
Mengamankan Pola Akses Email Kasus Edge
Ada berbagai varian penerusan email dan pola akses yang ditangani Gmail untuk mengamankan tindakan dalam email. Pengukuran berikut dilakukan SELAIN pengukuran di atas:
Pola Akses
Tindakan Keamanan Tambahan
Penerusan Manual - Pengguna membuka email dan meneruskannya ke lebih banyak penerima
Penerusan tersebut selalu merusak tanda tangan DKIM, dan pengirim tidak lagi terdaftar di layanan. Tindakan dalam email ditolak.
Penerusan Otomatis ke Gmail - Pengguna membuat aturan penerusan di kotak surat user@acme.com ke kotak surat Gmail miliknya.
Gmail memverifikasi bahwa pengguna dapat mengirim sebagai user@acme.com (pengguna menyiapkan ini secara manual). Tindakan dalam email disetujui.
Pengambilan POP Gmail - Pengguna memberikan sandi untuk user@acme.com kepada Gmail dan Gmail mengambil semua email di sana melalui POP ke kotak masuk Gmail.
Tanda tangan DKIM dan integritas konten dipertahankan. Pengguna telah membuktikan akses ke user@acme.com. Tindakan dalam email adalah diterima.
Mengakses email Gmail dengan aplikasi pihak ketiga - Pengguna Gmail menggunakan aplikasi pihak ketiga (misalnya, Outlook atau Thunderbird) untuk mengakses email Gmail, atau meneruskan email Gmail-nya ke penyedia email lain.
Aplikasi atau layanan pihak ketiga dapat menggunakan informasi yang disematkan. Namun, aplikasi tidak akan dapat menghasilkan token autentikasi pembawa yang cocok dengan token Google, sehingga memberi pengirim kesempatan untuk menolak permintaan tindakan tersebut. Pengirim dapat memilih apakah mereka menolak atau menerima tindakan tanpa token pembawa, bergantung pada sensitivitas tindakan. Perhatikan bahwa token otorisasi pembawa dibuat menggunakan teknologi open source standar sehingga semua penyedia dan aplikasi email dapat membuatnya menggunakan kunci mereka sendiri.
[null,null,["Terakhir diperbarui pada 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. |"]]
