Các biện pháp bổ sung cần thiết cho Thao tác trong dòng
Bạn cần hoặc nên áp dụng các biện pháp bảo mật bổ sung để bảo mật các thao tác nội tuyến:
HTTPS: Tất cả các thao tác phải được xử lý thông qua URL HTTPS. Máy chủ lưu trữ phải cài đặt chứng chỉ máy chủ SSL hợp lệ.
Mã truy cập: Người gửi sử dụng các thao tác được khuyến khích nhúng Mã truy cập dùng một lần vào URL của thao tác để tự bảo vệ mình khỏi Tấn công phát lại. Đây thường là một phương pháp hay cho mọi URL được nhúng trong các trang web hoặc email có thể gây ra bất kỳ tác dụng phụ nào khi được gọi.
Uỷ quyền cho người mang: Các dịch vụ xử lý yêu cầu hành động nên xác minh tiêu đề "Uỷ quyền" của Http trong yêu cầu HTTPS. Tiêu đề đó sẽ chứa một chuỗi "Bearer Token", chứng minh rằng nguồn của yêu cầu là google.com và yêu cầu đó dành cho dịch vụ được chỉ định. Các dịch vụ nên sử dụng thư viện nguồn mở do Google cung cấp để Xác minh mã thông báo của người mang.
Bảo mật các mẫu truy cập email trong trường hợp đặc biệt
Gmail xử lý nhiều biến thể của tính năng chuyển tiếp email và các mẫu truy cập để bảo mật các thao tác trong email. Những phép đo sau đây được thực hiện NGOÀI các phép đo nêu trên:
Mẫu truy cập
Các biện pháp bảo mật bổ sung
Chuyển tiếp thủ công – Người dùng mở một email và chuyển tiếp email đó cho nhiều người nhận khác
Việc chuyển tiếp như vậy luôn làm hỏng chữ ký DKIM và người gửi không còn được đăng ký với dịch vụ nữa. Các thao tác trong email sẽ bị từ chối.
Tự động chuyển tiếp đến Gmail – Người dùng tạo một quy tắc chuyển tiếp trên hộp thư user@acme.com đến hộp thư Gmail của họ.
Gmail xác minh rằng người dùng có thể gửi email dưới dạng user@acme.com (người dùng thiết lập việc này theo cách thủ công). Các hành động trong email sẽ được chấp nhận.
Gmail truy xuất qua POP – Người dùng cung cấp mật khẩu cho Gmail đối với địa chỉ email nguoidung@acme.com và Gmail sẽ truy xuất tất cả email tại địa chỉ đó qua POP vào hộp thư đến của Gmail.
Chữ ký DKIM và tính toàn vẹn của nội dung được giữ nguyên. Người dùng đã chứng minh quyền truy cập vào user@acme.com. Các thao tác trong email được chấp nhận.
Truy cập email trong Gmail bằng ứng dụng bên thứ ba – Người dùng Gmail sử dụng ứng dụng bên thứ ba (ví dụ: Outlook hoặc Thunderbird) để truy cập email trong Gmail hoặc chuyển tiếp email trong Gmail của mình đến một nhà cung cấp dịch vụ email khác.
Ứng dụng hoặc dịch vụ bên thứ ba có thể sử dụng thông tin được nhúng. Tuy nhiên, nó sẽ không thể tạo ra các mã thông báo xác thực của người mang khớp với mã thông báo của Google, giúp người gửi có cơ hội từ chối các yêu cầu hành động như vậy. Người gửi có thể chọn từ chối hoặc chấp nhận các hành động không có mã thông báo của người mang, tuỳ thuộc vào mức độ nhạy cảm của hành động. Xin lưu ý rằng mã thông báo uỷ quyền của người mang được tạo bằng các công nghệ nguồn mở tiêu chuẩn, cho phép tất cả các nhà cung cấp dịch vụ và ứng dụng thư tạo mã thông báo này bằng khoá riêng của họ.
[null,null,["Cập nhật lần gần đây nhất: 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. |"]]
