HTTPS: 모든 작업은 HTTPS URL을 통해 처리해야 합니다. 호스트에는 유효한 SSL 서버 인증서가 설치되어 있어야 합니다.
액세스 토큰: 작업을 사용하는 발신자는 재생 공격으로부터 보호하기 위해 작업 URL에 제한된 사용 액세스 토큰을 삽입하는 것이 권장됩니다. 이는 호출 시 부작용이 발생할 수 있는 웹페이지 또는 이메일에 삽입된 모든 URL에 일반적으로 권장되는 방법입니다.
Bearer 승인: 작업 요청을 처리하는 서비스는 HTTPS 요청에서 HTTP '승인' 헤더를 확인하는 것이 좋습니다. 이 헤더에는 요청의 소스가 google.com이고 요청이 지정된 서비스를 위한 것임을 증명하는 'Bearer Token' 문자열이 포함됩니다. 서비스는 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에 액세스할 수 있음을 증명했습니다. 이메일의 작업이 수락됩니다.
서드 파티 애플리케이션으로 Gmail 이메일에 액세스 - Gmail 사용자가 서드 파티 애플리케이션 (예: Outlook 또는 Thunderbird)을 사용하여 Gmail 이메일에 액세스하거나 Gmail 이메일을 다른 이메일 제공업체로 전달합니다.
서드 파티 애플리케이션 또는 서비스에서 삽입된 정보를 사용할 수 있습니다. 하지만 Google과 일치하는 운반자 인증 토큰을 생성할 수 없으므로 발신자가 이러한 작업 요청을 거부할 수 있습니다. 발신자는 작업의 민감도에 따라 베어러 토큰이 없는 작업을 거부할지 수락할지 선택할 수 있습니다. 전달자 승인 토큰은 표준 오픈소스 기술을 사용하여 생성되므로 모든 메일 제공업체와 앱이 자체 키를 사용하여 토큰을 생성할 수 있습니다.
[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. |"]]
