Signature des payloads

Chaque payload — la charge utile — que FortressFlag envoie à l’une de vos apps porte une signature, et chaque SDK la vérifie avant qu’une seule valeur de flag ne change. Vous n’avez rien à faire pour en bénéficier : les SDK embarquent la clé publique de production et vérifient par défaut. Cette page explique ce que ça vous apporte, ce que signifient les deux réglages de politique, et à quelles clés vos apps font confiance aujourd’hui.

Ce qui est signé, et pourquoi

Quand votre app interroge FortressFlag, la réponse contient deux choses : le payload (les valeurs de flags de votre appareil sur le plan client, le ruleset complet sur le plan serveur) et une signature sur les octets exacts de ce payload. La signature est produite avec une clé privée que seul FortressFlag détient ; votre SDK la vérifie avec la clé publique correspondante, livrée avec lui.

Si les octets ont été modifiés quelque part entre nos serveurs et votre app — un proxy, un CDN, un fichier de cache que quelqu’un a édité sur l’appareil — la vérification échoue et le SDK ignore la réponse. Il continue de servir les dernières valeurs qu’il a vérifiées (voir la promesse de repli) plutôt que de faire confiance à des octets dont il ne peut pas répondre.

Deux choses que la signature ne fait pas, pour que personne ne s’y fie à l’excès :

Elle ne cache rien. Le payload n’est pas chiffré — une clé client est publique par conception, et tout ce qui est servi avec elle l’est aussi. Ne mettez pas de secrets ni de données personnelles de vos utilisateurs dans les règles.
Elle ne remplace pas TLS. Les SDK parlent aussi à FortressFlag en HTTPS ; la signature est le second verrou, pour les parties du chemin que TLS ne couvre pas (caches, stockage sur l’appareil).

Les deux politiques

Chaque SDK a une politique de signature avec deux réglages :

required — la valeur par défaut. Le SDK vérifie chaque payload contre ses clés de confiance et rejette tout ce qui n’est pas signé, signé avec une clé qu’il ne connaît pas, ou signé sur d’autres octets. C’est ce que vous voulez dans chaque build qui parle à FortressFlag.
disabled — accepter les payloads non signés. Il n’existe que pour une situation : tourner contre un backend FortressFlag local sans clé de signature configurée. C’est un réglage nommé, que l’on retrouve avec grep, plutôt qu’un repli silencieux, pour que « pourquoi ça ne vérifie pas ? » ait toujours une réponse dans votre propre code source. Ne livrez jamais un build de production avec ce réglage.

Il n’y a pas de mode « avertissement » entre les deux. Un payload est vérifié, ou il est ignoré.

Les clés auxquelles vos apps font confiance

FortressFlag signe avec une clé par environnement, et les SDK ne font confiance qu’à la clé de production en sortant de la boîte. Si vous testez contre staging (fortressflag.net), ajoutez explicitement la clé de staging aux clés de confiance de votre SDK.

Environnement	Identifiant de clé	Clé publique (base64url)
Production (`fortressflag.com`)	`prod-2026-09-k1`	`EaEF8MHNu3onHxemTg3-OcrKrq7ODsZIVEp-IVV2ojg`
Staging (`fortressflag.net`)	`staging-2026-09-k1`	`RHFhzt8i3hQ4NKv_IrB92YuXmyNfDXx8eWN8cOrEBc8`

Les mêmes clés en octets bruts, en hexadécimal, si c’est ce que votre configuration attend :

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

Chaque clé est une clé publique Ed25519 de 32 octets. L’identifiant de clé est la partie centrale de chaque signature (ed25519:prod-2026-09-k1:…) — c’est ainsi que le SDK sait avec quelle clé vérifier. Ces valeurs sont publiques : vous pouvez les coller dans un fichier de configuration ou un dépôt sans hésiter.

Rotation

Quand FortressFlag fait tourner une clé, la nouvelle clé publique arrive d’abord dans une version du SDK, et nous ne commençons à signer avec elle qu’une fois que les SDK déployés lui font confiance. Une rotation ne vous oblige jamais à publier une app avant une date limite : un SDK qui fait confiance à l’ancienne et à la nouvelle clé continue de vérifier tout du long.

Si vous êtes sur le web

Le SDK web vérifie avec la Web Crypto intégrée à votre navigateur. Cela demande la prise en charge d’Ed25519 — Safari 17+, Chrome 137+, Firefox 130+ — et un contexte sécurisé (secure context) : les pages https:// et http://localhost. Sur une simple page http:// servie depuis, disons, une adresse du réseau local, les navigateurs n’exposent pas Web Crypto du tout.

Là où le navigateur ne peut pas vérifier, le SDK ne fait pas semblant de l’avoir fait, et ne jette pas non plus un bon cache. Il signale le payload comme invérifiable, continue de servir ses dernières valeurs vérifiées ou les valeurs par défaut de votre code, et journalise la raison une fois. Servez votre app en HTTPS et la question ne se posera jamais.

Où aller ensuite

Comment les flags arrivent à votre app — les deux plans et la promesse de repli sous les deux
Clés — pourquoi ffc_ est publique et ffs_ est un secret