כדי לאבטח פעולות מוטבעות, צריך להשתמש באמצעי אבטחה נוספים או מומלץ להשתמש בהם:
HTTPS: כל הפעולות חייבות להתבצע באמצעות כתובות URL מסוג HTTPS. למארחים צריכים להיות אישורי שרת SSL תקפים.
טוקנים לגישה: מומלץ לשולחים שמשתמשים בפעולות להטמיע טוקנים לגישה לשימוש מוגבל בכתובות ה-URL של הפעולות, כדי להגן על עצמם מפני התקפות חוזרות. זו בדרך כלל שיטה מומלצת לכל כתובת URL שמוטמעת בדפי אינטרנט או באימיילים, שיכולות להיות לה תופעות לוואי כשמפעילים אותה.
אימות באמצעות טוקן Bearer: מומלץ ששירותים שמטפלים בבקשות לפעולה יאמתו את כותרת ה-HTTP Authorization בבקשת ה-HTTPS. הכותרת הזו תכיל מחרוזת של Bearer Token, שמוכיחה שמקור הבקשה הוא google.com, ושמיועדת לשירות שצוין. השירותים צריכים להשתמש בספריית הקוד הפתוח ש-Google מספקת כדי לאמת את אסימון ה-Bearer.
אבטחת דפוסי גישה לאימייל במקרי קצה
יש וריאציות שונות של העברת אימייל ודפוסי גישה ש-Gmail מטפל בהם כדי לאבטח פעולות באימיילים. המדדים הבאים מחושבים בנוסף למדדים שצוינו למעלה:
דפוס הגישה
אמצעי אבטחה נוספים
העברה ידנית – המשתמש פותח אימייל ומעביר אותו לנמענים נוספים
העברה כזו תמיד גורמת לשבירה של חתימות DKIM, והשולח כבר לא רשום בשירות. הפעולות באימייל נדחות.
העברה אוטומטית ל-Gmail – משתמש יוצר כלל העברה בתיבת הדואר user@acme.com לתיבת הדואר שלו ב-Gmail.
מערכת Gmail מאמתת שהמשתמש יכול לשלוח אימייל בתור user@acme.com (המשתמש מגדיר את זה באופן ידני). הפעולות באימייל אושרו.
אחזור הודעות ב-Gmail באמצעות POP – המשתמש נותן ל-Gmail את הסיסמה של user@acme.com ו-Gmail מאחזר את כל האימיילים באמצעות POP לתיבת הדואר הנכנס של Gmail.
חתימות ה-DKIM והשלמות של התוכן נשמרות. המשתמש הוכיח שיש לו גישה לכתובת user@acme.com. הפעולות באימייל הן accepted.
גישה להודעות אימייל ב-Gmail באמצעות אפליקציות של צד שלישי – משתמש Gmail ניגש להודעות אימייל ב-Gmail באמצעות אפליקציה של צד שלישי (למשל Outlook או Thunderbird), או מעביר את הודעות האימייל שלו ב-Gmail לספק אימייל אחר.
יכול להיות שאפליקציה או שירות של צד שלישי ישתמשו במידע מוטמע. עם זאת, הוא לא יוכל ליצור אסימוני אימות מסוג bearer שתואמים לאסימונים של Google, ולכן השולחים יוכלו לדחות בקשות כאלה לפעולה. השולחים יכולים לבחור אם לדחות או לאשר פעולות ללא טוקנים מסוג bearer, בהתאם לרגישות של הפעולה. חשוב לציין שאסימון ההרשאה מסוג bearer נוצר באמצעות טכנולוגיות סטנדרטיות של קוד פתוח, כך שכל ספקי האימייל והאפליקציות יכולים ליצור אותו באמצעות המפתחות שלהם.
[null,null,["עדכון אחרון: 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. |"]]
