Ga naar inhoud
FortressFlag Docs

Payload-ondertekening

Elke payload die FortressFlag naar een van je apps stuurt draagt een handtekening, en elke SDK controleert die voordat er ook maar één flagwaarde verandert. Je hoeft hier niets voor te doen — de SDK’s worden geleverd met de publieke productiesleutel ingebouwd en verifiëren standaard. Deze pagina legt uit wat je daaraan hebt, wat de twee beleidsinstellingen betekenen, en welke sleutels je apps vandaag vertrouwen.

Wat er wordt ondertekend, en waarom

Section titled “Wat er wordt ondertekend, en waarom”

Wanneer je app polt, antwoordt FortressFlag met twee dingen: de payload (de flagwaarden van je apparaat op het client plane, de volledige ruleset op het server plane) en een handtekening over de exacte bytes van die payload. De handtekening wordt gemaakt met een privésleutel die alleen FortressFlag heeft; je SDK controleert hem met de bijbehorende publieke sleutel die hij meekreeg.

Als de bytes ergens tussen onze servers en je app zijn veranderd — een proxy, een CDN, een cachebestand dat iemand op het apparaat heeft bewerkt — mislukt de controle en negeert de SDK het antwoord. Hij blijft de laatst geverifieerde waarden serveren (zie de fallback-belofte) in plaats van bytes te vertrouwen waar hij niet voor kan instaan.

Twee dingen die de handtekening niet doet, zodat niemand er te veel op leunt:

  • Hij verbergt niets. De payload is niet versleuteld — een clientsleutel is publiek by design, en dat geldt ook voor alles wat ertegen wordt geserveerd. Stop geen geheimen of persoonsgegevens van je gebruikers in regels.
  • Hij vervangt TLS niet. De SDK’s praten ook via HTTPS met FortressFlag; de handtekening is het tweede slot, voor de delen van het pad die TLS niet dekt (caches, opslag op het apparaat).

De twee beleidsinstellingen

Section titled “De twee beleidsinstellingen”

Elke SDK heeft een handtekeningbeleid met twee instellingen:

  • required — de standaard. De SDK verifieert elke payload tegen zijn vertrouwde sleutels en wijst alles af dat niet ondertekend is, ondertekend is met een sleutel die hij niet kent, of ondertekend is over andere bytes. Dit is wat je wilt in elke build die met FortressFlag praat.
  • disabled — accepteer niet-ondertekende payloads. Het bestaat voor één situatie: draaien tegen een lokale FortressFlag-backend waar geen ondertekeningssleutel is geconfigureerd. Het is een benoemde, greppable instelling in plaats van een stille fallback, zodat “waarom verifieert dit niet?” altijd een antwoord heeft in je eigen broncode. Verscheep nooit een productiebuild met deze instelling.

Er zit geen “waarschuw”-modus tussenin. Een payload verifieert, of hij wordt genegeerd.

De sleutels die je apps vertrouwen

Section titled “De sleutels die je apps vertrouwen”

FortressFlag ondertekent met één sleutel per omgeving, en de SDK’s worden geleverd met alleen vertrouwen in de productiesleutel. Test je tegen staging (fortressflag.net), voeg dan de stagingsleutel expliciet toe aan de vertrouwde sleutels van je SDK.

Omgeving Sleutel-id Publieke sleutel (base64url)
Productie (fortressflag.com) prod-2026-09-k1 EaEF8MHNu3onHxemTg3-OcrKrq7ODsZIVEp-IVV2ojg
Staging (fortressflag.net) staging-2026-09-k1 RHFhzt8i3hQ4NKv_IrB92YuXmyNfDXx8eWN8cOrEBc8

Dezelfde sleutels als ruwe bytes, in hex, als je configuratie dat verwacht:

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

Elke sleutel is een 32-byte Ed25519 publieke sleutel. De sleutel-id is het middelste deel van elke handtekening (ed25519:prod-2026-09-k1:…), en zo weet de SDK met welke sleutel hij moet controleren. Deze waarden zijn publiek — je kunt ze zonder aarzelen in een configuratiebestand of een repository plakken.

Rotatie

Section titled “Rotatie”

Wanneer FortressFlag een sleutel roteert, verschijnt de nieuwe publieke sleutel eerst in een SDK-release, en we beginnen er pas mee te ondertekenen zodra de SDK’s in het veld hem vertrouwen. Rotatie dwingt je nooit om een app op een deadline uit te brengen: een SDK die zowel de oude als de nieuwe sleutel vertrouwt, blijft de hele tijd verifiëren.

Als je op het web zit

Section titled “Als je op het web zit”

De web-SDK verifieert met de ingebouwde Web Crypto van je browser. Dat vereist Ed25519-ondersteuning — Safari 17+, Chrome 137+, Firefox 130+ — en een secure context: https://-pagina’s en http://localhost. Op een gewone http://-pagina die bijvoorbeeld van een LAN-adres wordt geserveerd, stellen browsers Web Crypto helemaal niet beschikbaar.

Waar de browser niet kan verifiëren, doet de SDK niet alsof hij dat wel deed en gooit hij ook geen goede cache weg. Hij rapporteert de payload als niet-verifieerbaar, blijft zijn laatst geverifieerde waarden of de standaarden van je code serveren, en logt de reden één keer. Serveer je app via HTTPS en dit komt nooit ter sprake.

Waar nu heen?

Section titled “Waar nu heen?”