Firma dei payload

Ogni payload che FortressFlag invia a una delle tue app porta una firma, e ogni SDK la verifica prima che un solo valore di flag cambi. Non devi fare nulla per averla: gli SDK escono con la chiave pubblica di produzione già inclusa e verificano per impostazione predefinita. Questa pagina spiega cosa ti garantisce, cosa significano le due impostazioni della policy e di quali chiavi le tue app si fidano oggi.

Cosa viene firmato, e perché

Quando la tua app fa poll, FortressFlag risponde con due cose: il payload (i valori di flag del tuo dispositivo sul piano client, il ruleset completo sul piano server) e una firma sui byte esatti di quel payload. La firma è prodotta con una chiave privata che solo FortressFlag possiede; il tuo SDK la verifica con la chiave pubblica corrispondente che porta con sé.

Se i byte sono stati modificati in un punto qualsiasi tra i nostri server e la tua app — un proxy, una CDN, un file di cache che qualcuno ha modificato sul dispositivo — la verifica fallisce e l’SDK ignora la risposta. Continua a servire gli ultimi valori che ha verificato (vedi la promessa di fallback) invece di fidarsi di byte per cui non può garantire.

Due cose che la firma non fa, così nessuno ci fa troppo affidamento:

Non nasconde nulla. Il payload non è cifrato — una chiave client è pubblica per progettazione, e lo è anche tutto ciò che viene servito con essa. Non mettere segreti o dati personali dei tuoi utenti nelle regole.
Non sostituisce TLS. Gli SDK parlano con FortressFlag anche via HTTPS; la firma è la seconda serratura, per i tratti del percorso che TLS non copre (cache, storage sul dispositivo).

Le due policy

Ogni SDK ha una policy di firma con due impostazioni:

required — l’impostazione predefinita. L’SDK verifica ogni payload contro le sue chiavi fidate e rifiuta qualsiasi cosa non firmata, firmata con una chiave che non conosce o firmata su byte diversi. È ciò che vuoi in ogni build che parla con FortressFlag.
disabled — accetta payload non firmati. Esiste per una sola situazione: girare contro un backend FortressFlag locale senza alcuna chiave di firma configurata. È un’impostazione con un nome, trovabile con grep, non un fallback silenzioso, così «perché non sta verificando?» ha sempre una risposta nel tuo stesso codice sorgente. Non rilasciare mai una build di produzione con questa impostazione.

Non c’è nessuna modalità «warn» a metà strada. Un payload o viene verificato o viene ignorato.

Le chiavi di cui le tue app si fidano

FortressFlag firma con una chiave per ambiente, e gli SDK escono fidandosi solo della chiave di produzione. Se fai test contro staging (fortressflag.net), aggiungi esplicitamente la chiave di staging alle chiavi fidate del tuo SDK.

Ambiente	Id chiave	Chiave pubblica (base64url)
Produzione (`fortressflag.com`)	`prod-2026-09-k1`	`EaEF8MHNu3onHxemTg3-OcrKrq7ODsZIVEp-IVV2ojg`
Staging (`fortressflag.net`)	`staging-2026-09-k1`	`RHFhzt8i3hQ4NKv_IrB92YuXmyNfDXx8eWN8cOrEBc8`

Le stesse chiavi come byte grezzi, in esadecimale, se è questo che accetta la tua configurazione:

prod-2026-09-k1     11a105f0c1cdbb7a271f17a64e0dfe39cacaaeaece0ec648544a7e215576a238
staging-2026-09-k1  447161cedf22de143834abff22b07dd98b979b235f0d7c7c79637c70eac405cf

Ogni chiave è una chiave pubblica Ed25519 da 32 byte. L’id chiave è la parte centrale di ogni firma (ed25519:prod-2026-09-k1:…), ed è così che l’SDK sa con quale chiave verificare. Questi valori sono pubblici — puoi incollarli in un file di configurazione o in un repository senza pensarci due volte.

Rotazione

Quando FortressFlag ruota una chiave, la nuova chiave pubblica esce prima in una release dell’SDK, e iniziamo a firmare con essa solo quando gli SDK in circolazione se ne fidano. La rotazione non ti obbliga mai a rilasciare un’app entro una scadenza: un SDK che si fida sia della chiave vecchia sia della nuova continua a verificare per tutto il tempo.

Se sei sul web

L’SDK web verifica con la Web Crypto integrata nel tuo browser. Serve il supporto a Ed25519 — Safari 17+, Chrome 137+, Firefox 130+ — e un contesto sicuro: pagine https:// e http://localhost. Su una semplice pagina http:// servita, per esempio, da un indirizzo di LAN, i browser non espongono affatto la Web Crypto.

Dove il browser non può verificare, l’SDK non finge di averlo fatto e non butta via nemmeno una cache buona. Segnala il payload come non verificabile, continua a servire gli ultimi valori verificati o i valori predefiniti del tuo codice, e registra il motivo una sola volta. Servi la tua app via HTTPS e questo non si presenterà mai.

Prossimi passi

Come i flag raggiungono la tua app — i due piani e la promessa di fallback sotto entrambi
Chiavi — perché ffc_ è pubblica e ffs_ è un segreto