Domini consentiti

I domini consentiti (una allowlist di domini) garantiscono che la tua chiave pubblica funzioni solo sui tuoi siti. Ogni richiesta con chiave pubblica viene confrontata con la lista usando l’header Origin del browser (oppure Referer quando Origin manca). Le richieste da altre origini vengono rifiutate con 403 origin_not_allowed e non consumano crediti.

I domini consentiti sono disponibili su tutti i piani, incluso Free.

Configurazione

Proprietari e admin aggiungono le voci in Sicurezza → Siti consentiti: scrivi un dominio, fai clic su Aggiungi (una voce alla volta, fino a 100) e salva. Le voci vengono confrontate con l’host dell’origine della richiesta; lo schema (http/https) non conta.

Voce	Corrisponde a
example.com	https://example.com e http://example.com su qualsiasi porta – ma non www.example.com
*.example.com	qualsiasi sottodominio: www.example.com, shop.eu.example.com – ma non example.com stesso
localhost	sviluppo locale su qualsiasi porta
localhost:3000	solo quella porta
127.0.0.1	sviluppo locale tramite IP
my-app.pages.dev	deploy di anteprima presso un provider di hosting

Aggiungi sia example.com sia *.example.com se ti servono il dominio principale e i sottodomini.

Attenzione

Una lista vuota consente qualsiasi origine web. La dashboard te lo segnala (Nessun dominio impostato: qualsiasi sito può usare la tua chiave pubblica); non andare in produzione senza almeno il tuo dominio di produzione nella lista. Le richieste senza header Origin o Referer (server, curl, app native) vengono rifiutate che la lista sia vuota o no – a meno che tu non consenta le app mobile.

App mobile

Le app native (React Native, Flutter, Swift, Kotlin) non inviano né Origin né Referer, quindi l’API pubblica le rifiuta per impostazione predefinita (come EmailJS, che blocca le richieste non provenienti da browser finché non le abiliti). Per inviare da un’app con la chiave pubblica, attiva Sicurezza → App mobile → Consenti app mobile (disattivato per impostazione predefinita) e fai clic su Salva. A quel punto:

Richiesta	App mobile off, lista vuota	App mobile off, lista impostata	App mobile on, lista vuota	App mobile on, lista impostata
Origin / Referer nella lista	accettata	accettata	accettata	accettata
Origin / Referer non nella lista	accettata	403 origin_not_allowed	accettata	403 origin_not_allowed
né Origin né Referer (app nativa, server, curl)	403 origin_not_allowed	403 origin_not_allowed	accettata	accettata
Origin: null	accettata	403 origin_not_allowed	accettata	403 origin_not_allowed

L’errore per una richiesta senza Origin ha details.reason: "no_origin". Consentire le app mobile decide anche quale chiave CAPTCHA verifica queste richieste: solo con l’interruttore attivo vengono verificate con il widget mobile condiviso di Frontmail (vedi Turnstile).

Cambiato a settembre 2026

In precedenza una lista vuota accettava anche le richieste senza Origin/Referer. Alle organizzazioni che avevano inviato richieste di questo tipo negli ultimi 30 giorni è stato attivato automaticamente Consenti app mobile durante l’aggiornamento, così le loro app continuano a funzionare. Per tutti gli altri, l’invio lato server con la chiave pubblica ora fallisce con 403 origin_not_allowed: sui server usa una chiave privata.

Le richieste che portano un Origin o un Referer vengono sempre confrontate con la lista, quindi attivare l’interruttore non indebolisce la protezione dei tuoi siti. Origin: null (iframe in sandbox, pagine file://) non viene considerato un’app mobile. Turnstile resta obbligatorio per ogni modello in cui è attivo. La modifica viene registrata nel registro attività come security.updated.

Attenzione

Con le app mobile consentite, le richieste senza header Origin vengono accettate da qualsiasi parte: qualunque script o server che conosca la tua chiave pubblica può inviarle. Affidati ai rate limit, a Turnstile e alla lista dei bloccati, e non inserire mai una chiave privata in un’app. Vedi React Native.

Da cosa protegge e da cosa no

I browser impostano Origin da soli e gli script non possono falsificarlo, quindi la allowlist impedisce ad altri siti di incorporare la tua chiave. Uno script eseguito fuori da un browser (curl, un bot) può però inviare qualsiasi header Origin. Ecco perché i domini consentiti sono solo uno strato, combinato con Turnstile, i rate limit e la protezione dai bot.

Le richieste con una chiave privata saltano il controllo dell’origine: arrivano dai server, che non hanno un’origine. Una richiesta con chiave privata che porta un header Origin arriva da una pagina web, dove ogni visitatore può leggere la chiave; viene rifiutata con 403 private_key_in_browser, a meno che tu non attivi Consenti chiavi private nei browser (vedi Chiavi).

Risoluzione dei problemi

• Funziona in locale, fallisce in produzione: aggiungi il dominio di produzione (e la variante www.).
• Fallisce in un’app nativa o da uno script server (403 origin_not_allowed, details.reason: "no_origin"): per le app attiva Consenti app mobile; sui server usa una chiave privata.
• Fallisce in una WebView mobile o in un’estensione del browser: l’origine potrebbe essere null, file:// o chrome-extension://…. Invia invece dal tuo backend con una chiave privata.
• Fallisce dietro un’estensione per la privacy che rimuove il Referer: i browser moderni inviano sempre Origin nelle richieste POST, quindi è raro; controlla la richiesta nei DevTools.

Nella dashboard

Vedi Impostazioni di sicurezza per una panoramica della pagina Sicurezza.