Assinatura de payloads

Todo payload que o FortressFlag envia a um dos seus apps carrega uma assinatura, e todo SDK a verifica antes que um único valor de flag mude. Você não precisa fazer nada para ter isso — os SDKs já vêm com a chave pública de produção embutida e verificam por padrão. Esta página explica o que isso garante a você, o que significam as duas configurações de política e em quais chaves os seus apps confiam hoje.

O que é assinado, e por quê

Quando o seu app faz polling, o FortressFlag responde com duas coisas: o payload (os valores de flag do seu dispositivo no client plane, o ruleset completo no server plane) e uma assinatura sobre os bytes exatos desse payload. A assinatura é feita com uma chave privada que só o FortressFlag tem; o seu SDK a verifica com a chave pública correspondente que veio embutida nele.

Se os bytes foram alterados em qualquer ponto entre os nossos servidores e o seu app — um proxy, uma CDN, um arquivo de cache que alguém editou no dispositivo — a verificação falha e o SDK ignora a resposta. Ele continua servindo os últimos valores que verificou (veja a promessa de fallback) em vez de confiar em bytes pelos quais não pode responder.

Duas coisas que a assinatura não faz, para ninguém depender demais dela:

Ela não esconde nada. O payload não é criptografado — uma chave de cliente é pública por design, e tudo o que é servido com ela também. Não coloque segredos nem dados pessoais dos seus usuários em regras.
Ela não substitui o TLS. Os SDKs também falam com o FortressFlag por HTTPS; a assinatura é a segunda tranca, para os trechos do caminho que o TLS não cobre (caches, armazenamento no dispositivo).

As duas políticas

Todo SDK tem uma política de assinatura com duas configurações:

required — o padrão. O SDK verifica todo payload contra as suas chaves confiáveis e rejeita qualquer coisa sem assinatura, assinada com uma chave que ele não conhece ou assinada sobre bytes diferentes. É o que você quer em todo build que fala com o FortressFlag.
disabled — aceitar payloads sem assinatura. Existe para uma única situação: rodar contra um backend local do FortressFlag que não tem nenhuma chave de assinatura configurada. É uma configuração com nome, que dá para achar com grep, e não um fallback silencioso, para que “por que isso não está verificando?” sempre tenha resposta no seu próprio código-fonte. Nunca publique um build de produção com ela.

Não existe um modo “warn” no meio do caminho. Um payload ou é verificado ou é ignorado.

As chaves em que os seus apps confiam

O FortressFlag assina com uma chave por ambiente, e os SDKs vêm confiando só na chave de produção. Se você testa contra o staging (fortressflag.net), adicione a chave de staging às chaves confiáveis do seu SDK explicitamente.

Ambiente	ID da chave	Chave pública (base64url)
Produção (`fortressflag.com`)	`prod-2026-09-k1`	`EaEF8MHNu3onHxemTg3-OcrKrq7ODsZIVEp-IVV2ojg`
Staging (`fortressflag.net`)	`staging-2026-09-k1`	`RHFhzt8i3hQ4NKv_IrB92YuXmyNfDXx8eWN8cOrEBc8`

As mesmas chaves como bytes brutos, em hexadecimal, se é isso que a sua configuração aceita:

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

Cada chave é uma chave pública Ed25519 de 32 bytes. O ID da chave é a parte do meio de toda assinatura (ed25519:prod-2026-09-k1:…), e é assim que o SDK sabe com qual chave verificar. Esses valores são públicos — você pode colá-los em um arquivo de configuração ou em um repositório sem pensar duas vezes.

Rotação

Quando o FortressFlag rotaciona uma chave, a nova chave pública sai primeiro em uma release do SDK, e só começamos a assinar com ela quando os SDKs em circulação já confiam nela. A rotação nunca exige que você publique um app com prazo: um SDK que confia tanto na chave antiga quanto na nova continua verificando o tempo todo.

Se você está na web

O SDK web verifica com a Web Crypto embutida no seu navegador. Isso exige suporte a Ed25519 — Safari 17+, Chrome 137+, Firefox 130+ — e um contexto seguro: páginas https:// e http://localhost. Em uma página http:// simples servida de, digamos, um endereço da LAN, os navegadores nem expõem a Web Crypto.

Onde o navegador não consegue verificar, o SDK não finge que verificou e também não joga fora um cache bom. Ele reporta o payload como não verificável, continua servindo os últimos valores verificados ou os padrões do seu código, e registra o motivo uma vez. Sirva o seu app por HTTPS e isso nunca aparece.

Para onde ir agora

Como as flags chegam ao seu app — os dois planes e a promessa de fallback por baixo dos dois
Chaves — por que ffc_ é pública e ffs_ é um segredo