Firma de payloads

Cada carga útil que FortressFlag envía a una de tus apps lleva una firma, y cada SDK la comprueba antes de que cambie un solo valor de flag. No tienes que hacer nada para conseguirlo: los SDK vienen con la clave pública de producción incorporada y verifican por defecto. Esta página explica qué te aporta eso, qué significan los dos ajustes de política y en qué claves confían hoy tus apps.

Qué se firma, y por qué

Cuando tu app sondea, FortressFlag responde con dos cosas: la carga útil (el payload: los valores de flag de tu dispositivo en el plano de cliente, el ruleset completo en el plano de servidor) y una firma sobre los bytes exactos de esa carga útil. La firma se genera con una clave privada que solo FortressFlag posee; tu SDK la comprueba con la clave pública correspondiente que lleva incorporada.

Si los bytes cambiaron en cualquier punto entre nuestros servidores y tu app — un proxy, una CDN, un archivo de caché que alguien editó en el dispositivo — la comprobación falla y el SDK ignora la respuesta. Sigue sirviendo los últimos valores que verificó (mira la promesa de respaldo) en lugar de fiarse de bytes que no puede avalar.

Dos cosas que la firma no hace, para que nadie confíe en ella de más:

No oculta nada. La carga útil no va cifrada — una clave de cliente es pública por diseño, y también lo es todo lo que se sirve con ella. No pongas secretos ni datos personales de tus usuarios en las reglas.
No sustituye a TLS. Los SDK también hablan con FortressFlag por HTTPS; la firma es el segundo cerrojo, para las partes del camino que TLS no cubre (cachés, almacenamiento en el dispositivo).

Las dos políticas

Cada SDK tiene una política de firma con dos ajustes:

required — el valor por defecto. El SDK verifica cada carga útil contra sus claves de confianza y rechaza cualquier cosa sin firmar, firmada con una clave que no conoce o firmada sobre bytes distintos. Es lo que quieres en cada build que hable con FortressFlag.
disabled — aceptar cargas útiles sin firmar. Existe para una sola situación: ejecutar contra un backend local de FortressFlag que no tiene ninguna clave de firma configurada. Es un ajuste con nombre, que puedes buscar con grep, y no un respaldo silencioso, para que «¿por qué no está verificando?» siempre tenga respuesta en tu propio código fuente. Nunca publiques un build de producción con él.

No hay ningún modo «warn» intermedio. Una carga útil o se verifica o se ignora.

Las claves en las que confían tus apps

FortressFlag firma con una clave por entorno, y los SDK vienen confiando solo en la clave de producción. Si haces pruebas contra staging (fortressflag.net), añade la clave de staging a las claves de confianza de tu SDK de forma explícita.

Entorno	Id de clave	Clave pública (base64url)
Producción (`fortressflag.com`)	`prod-2026-09-k1`	`EaEF8MHNu3onHxemTg3-OcrKrq7ODsZIVEp-IVV2ojg`
Staging (`fortressflag.net`)	`staging-2026-09-k1`	`RHFhzt8i3hQ4NKv_IrB92YuXmyNfDXx8eWN8cOrEBc8`

Las mismas claves como bytes en bruto, en hexadecimal, si es lo que acepta tu configuración:

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

Cada clave es una clave pública Ed25519 de 32 bytes. El id de clave es la parte central de cada firma (ed25519:prod-2026-09-k1:…), y así es como el SDK sabe con qué clave comprobar. Estos valores son públicos — puedes pegarlos en un archivo de configuración o en un repositorio sin pensarlo dos veces.

Rotación

Cuando FortressFlag rota una clave, la nueva clave pública sale primero en una versión del SDK, y solo empezamos a firmar con ella cuando los SDK que ya están en circulación confían en ella. La rotación nunca te obliga a publicar una app con fecha límite: un SDK que confía tanto en la clave antigua como en la nueva sigue verificando durante todo el proceso.

Si estás en la web

El SDK web verifica con la Web Crypto integrada en tu navegador. Eso requiere soporte de Ed25519 — Safari 17+, Chrome 137+, Firefox 130+ — y un contexto seguro: páginas https:// y http://localhost. En una página http:// a secas servida desde, por ejemplo, una dirección de la LAN, los navegadores directamente no exponen Web Crypto.

Donde el navegador no puede verificar, el SDK no finge que lo hizo, y tampoco tira una caché buena. Marca la carga útil como no verificable, sigue sirviendo sus últimos valores verificados o los valores por defecto de tu código, y registra el motivo una sola vez. Sirve tu app por HTTPS y esto nunca llega a pasar.

¿Por dónde seguir?

Cómo llegan los flags a tu app — los dos planos y la promesa de respaldo debajo de ambos
Claves — por qué ffc_ es pública y ffs_ es un secreto