Misure aggiuntive richieste per le azioni in linea
Per proteggere le azioni in linea sono necessarie o consigliate misure di sicurezza aggiuntive:
HTTPS: tutte le azioni devono essere gestite tramite URL HTTPS. Gli host devono avere installato certificati server SSL validi.
Token di accesso: è consigliabile che i mittenti che utilizzano le azioni incorporino token di accesso a uso limitato negli URL delle azioni per proteggersi dagli attacchi di replay. Si tratta di una buona pratica generale per qualsiasi URL incorporato in pagine web o email che potrebbe avere effetti collaterali quando viene richiamato.
Autorizzazione Bearer: è consigliabile che i servizi che gestiscono le richieste di azioni verifichino l'intestazione HTTP "Authorization" nella richiesta HTTPS. L'intestazione conterrà una stringa "Bearer Token", che dimostra che l'origine della richiesta è google.com e che la richiesta è destinata al servizio specificato. I servizi devono utilizzare la libreria open source fornita da Google per verificare il token di tipo Bearer.
Protezione dei pattern di accesso alle email in casi limite
Esistono varie varianti di inoltro email e modelli di accesso che Gmail gestisce per proteggere le azioni nelle email. Le seguenti misurazioni vengono eseguite IN AGGIUNTA a quelle sopra indicate:
Pattern di accesso
Misure di sicurezza aggiuntive
Inoltro manuale: l'utente apre un'email e la inoltra ad altri destinatari
Questo tipo di inoltro danneggia sempre le firme DKIM e il mittente non è più registrato al servizio. Le azioni nell'email sono rifiutate.
Inoltro automatico a Gmail: l'utente crea una regola di inoltro nella casella postale user@acme.com alla sua casella postale Gmail.
Gmail verifica che l'utente possa inviare email come utente@acme.com (l'utente configura questa impostazione manualmente). Le azioni nell'email sono accettate.
Recupero POP di Gmail: l'utente fornisce a Gmail la password per user@acme.com e Gmail recupera tutte le email tramite POP nella posta in arrivo di Gmail.
Le firme DKIM e l'integrità dei contenuti vengono mantenute. L'utente ha dimostrato di avere accesso a user@acme.com. Le azioni nell'email sono accettate.
Accesso alle email di Gmail con applicazioni di terze parti: l'utente di Gmail utilizza un'applicazione di terze parti (ad es. Outlook o Thunderbird) per accedere alle email di Gmail o inoltra le sue email di Gmail a un altro provider di posta.
L'applicazione o il servizio di terze parti potrebbe utilizzare le informazioni incorporate. Tuttavia, non sarà in grado di produrre token di autenticazione bearer che corrispondano a quelli di Google, dando ai mittenti la possibilità di rifiutare tali richieste di azione. I mittenti possono scegliere se rifiutare o accettare le azioni senza token di autenticazione, a seconda della sensibilità dell'azione. Tieni presente che il token di autorizzazione bearer viene creato utilizzando tecnologie open source standard, il che consente a tutti i provider di posta e le app di produrli utilizzando le proprie chiavi.
[null,null,["Ultimo aggiornamento 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. |"]]
