اقدامات امنیتی اضافی برای ایمن سازی اقدامات درون خطی مورد نیاز یا تشویق می شود:
HTTPS : همه اقدامات باید از طریق URL های HTTPS انجام شوند. هاست ها باید گواهینامه های معتبر سرور SSL را نصب کرده باشند.
توکن‌های دسترسی : توصیه می‌شود فرستندگانی که از کنش‌ها استفاده می‌کنند، نشانه‌های دسترسی با استفاده محدود را در URLهای اقدام جاسازی کنند تا از خود در برابر حملات بازپخش محافظت کنند. این یک روش کلی برای هر URL تعبیه شده در صفحات وب یا ایمیل هایی است که ممکن است هنگام فراخوانی عوارض جانبی داشته باشد.
مجوز حامل : توصیه می‌شود که سرویس‌هایی که درخواست‌های کنش را مدیریت می‌کنند، سرصفحه «Authorization» Http را در درخواست HTTPS تأیید کنند. آن سرصفحه حاوی یک رشته "Token حامل" است که ثابت می کند منبع درخواست google.com است و این درخواست برای سرویس مشخص شده در نظر گرفته شده است. خدمات باید از کتابخانه منبع باز ارائه شده توسط Google برای تأیید توکن حامل استفاده کنند.
ایمن سازی الگوهای دسترسی به ایمیل Edge-Case
انواع مختلفی از الگوهای ارسال ایمیل و دسترسی وجود دارد که جیمیل به منظور ایمن سازی اقدامات در ایمیل ها از آنها استفاده می کند. این اندازه گیری های زیر علاوه بر اقدامات فوق انجام می شود:
الگوی دسترسی
اقدامات امنیتی اضافی
ارسال دستی - کاربر یک ایمیل را باز می کند و آن را به گیرندگان بیشتری ارسال می کند
چنین ارسالی همیشه امضاهای DKIM را می شکند و فرستنده دیگر در سرویس ثبت نام نمی کند. اقدامات در ایمیل رد می شود.
بازارسال خودکار به Gmail - کاربر یک قانون حمل و نقل در mailbox user@acme.com به صندوق پستی gmail خود ایجاد می کند.
Gmail تأیید می کند که کاربر می تواند به عنوان user@acme.com ارسال کند (کاربر این را به صورت دستی تنظیم می کند). اقدامات در ایمیل پذیرفته می شود.
واکشی Gmail POP - کاربر رمز عبور user@acme.com را به Gmail می‌دهد و Gmail همه ایمیل‌ها را از طریق POP به صندوق ورودی Gmail می‌آورد.
امضاهای DKIM و یکپارچگی محتوا حفظ می شود. دسترسی کاربر به user@acme.com ثابت شده است. اقدامات در ایمیل پذیرفته می شود.
دسترسی به ایمیل‌های Gmail با برنامه‌های شخص ثالث - کاربر Gmail از یک برنامه شخص ثالث (مثلاً Outlook یا Thunderbird) برای دسترسی به ایمیل‌های Gmail استفاده می‌کند یا ایمیل‌های Gmail خود را به ارائه‌دهنده ایمیل دیگری ارسال می‌کند.
برنامه یا سرویس شخص ثالث ممکن است از اطلاعات جاسازی شده استفاده کند. با این حال، نمی‌تواند نشانه‌های احراز هویت حامل مطابق با Google تولید کند و به فرستندگان این فرصت را می‌دهد که چنین درخواست‌هایی را رد کنند. بسته به حساسیت عمل، فرستندگان ممکن است انتخاب کنند که آیا اقدامات بدون علامت حامل را رد کنند یا بپذیرند. توجه داشته باشید که رمز مجوز حامل با استفاده از فناوری‌های منبع باز استاندارد ایجاد می‌شود که این امکان را برای همه ارائه‌دهندگان ایمیل و برنامه‌ها فراهم می‌کند تا با استفاده از کلیدهای خود آنها را تولید کنند.
تاریخ آخرین بهروزرسانی 2025-08-29 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-08-29 بهوقت ساعت هماهنگ جهانی."],[],[],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. |"]]
