DEV Community: Daniel Morfa Vega

Tu base de datos es tu backend: reglas de Firestore que no se fían ni de tu propio cliente

Daniel Morfa Vega — Thu, 27 Aug 2026 19:55:38 +0000

Cuentopia es una app Ionic + Angular que escribe cuentos para ayudar a las familias a explicar cosas difíciles a los peques. Por dentro es Firebase: el cliente habla directo con Firestore, sin un servidor mío en medio.

Eso es medio backend que no tengo que escribir, mantener ni pagar. También significa que mi base de datos está publicada en internet con una API REST y gRPC documentada, y que lo único que hay entre esa API y los datos de una familia son unas reglas declarativas que escribí yo.

Voy a contar cómo las pensé, con los tres bugs que me costaron una tarde cada uno.

Todo el código de este artículo es de una app inventada de avistamientos de aves, no de Cuentopia: mismos patrones, nombres y esquema distintos, por razones obvias. Es código real de reglas, no pseudocódigo.

Lo que Firestore te concede cuando no dices nada

Cuando abres un proyecto en modo de pruebas, Firestore te da esto:

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2026, 9, 21);
}

Acceso total a todo, para cualquiera, hasta una fecha. La consola te avisa. Casi nadie lo lee dos veces, porque durante las primeras semanas funciona perfecto: la app va, los datos se guardan, nada falla. El único síntoma de que no tienes seguridad es que todo va muy bien.

El paso siguiente que da casi todo el mundo, y que yo di también, es este:

match /{document=**} {
  allow read, write: if request.auth != null;
}

Esto no es seguridad. Es una lista de invitados con la puerta abierta. request.auth != null significa "alguien se autenticó", y en un proyecto con login por Google eso significa "cualquier persona del planeta con una cuenta de Google". Un usuario legítimo, con su sesión legítima, abre la consola del navegador, y desde ahí tiene exactamente los mismos permisos que tu app: leer cualquier documento de cualquier otro usuario, y escribir lo que le dé la gana en él.

La distinción que hay que tener grabada es autenticación contra autorización. Firestore te resuelve la primera. La segunda es tuya, entera, y se escribe aquí.

Deny-by-default no es la regla del final del archivo

Casi todas las guías terminan el archivo de reglas con esto:

match /{document=**} {
  allow read, write: if false;
}

Yo lo tengo. Y funciona. Pero durante un tiempo lo entendí mal, y creo que mucha gente lo entiende mal igual, así que conviene decirlo claro: ese bloque no es un cortafuegos que revoca nada.

Las reglas de Firestore no se evalúan en cascada como un firewall, donde la última coincidencia gana. Se evalúan como un OR: se busca cualquier regla allow cuyo match encaje con la ruta y cuya condición sea cierta. Si existe una sola, el acceso se concede. Ninguna regla puede quitar un permiso que otra ha dado. Un allow ...: if false no deniega: simplemente no concede.

O sea que el catch-all del final es, funcionalmente, un no-op. Su valor es documental: deja escrito que cualquier ruta no contemplada está cerrada, y que eso es deliberado. Lo mantengo por eso, y porque el día que alguien abra el archivo entienda de qué va la casa.

El deny-by-default de verdad es el comportamiento por defecto de la plataforma: si ninguna regla concede, se deniega. Lo cual invierte por completo dónde está el peligro. El peligro no es olvidarte de cerrar una colección nueva, porque nace cerrada. El peligro es haber dejado arriba un match /{document=**} permisivo, porque entonces da igual lo cuidadosas que sean tus reglas de abajo: ya hay un allow que encaja con todo y que concede antes de que las tuyas opinen.

Escribir reglas restrictivas debajo de una regla amplia y creer que las restringes es el error conceptual más caro de este modelo. No las restringes. Las estás decorando.

Un documento entrante es un payload que escribió un desconocido

Con eso claro, el resto del trabajo es aburrido en el buen sentido. Estos son los ayudantes que uso en todo el archivo:

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {

    function signedIn() {
      return request.auth != null;
    }

    function isOwner(uid) {
      return signedIn() && request.auth.uid == uid;
    }

    // Lista cerrada de claves. Si aparece una que no está, cae la escritura
    // ENTERA, no solo ese campo: no existe el "se guardó casi bien".
    function onlyKeys(data, keys) {
      return data.keys().hasOnly(keys);
    }

    // affectedKeys() es el conjunto de claves cuyo valor cambia en esta
    // escritura. Si alguna protegida está dentro, se rechaza.
    function unchanged(fields) {
      return fields.toSet().intersection(
        request.resource.data.diff(resource.data).affectedKeys()
      ).size() == 0;
    }

    function boundedString(value, min, max) {
      return value is string && value.size() >= min && value.size() <= max;
    }

Y así queda el documento de perfil:

    match /observers/{uid} {
      allow read: if isOwner(uid);

      allow create: if isOwner(uid)
        && onlyKeys(request.resource.data, [
             'uid', 'email', 'display_name',
             'tier', 'tier_status', 'credits',
             'preferences', 'created_at', 'updated_at'
           ])
        && request.resource.data.uid == uid
        // Todo el mundo nace en el plan gratis con el saldo a cero. Cualquier
        // otro valor solo puede venir del servidor, y el servidor no entra por
        // aquí.
        && request.resource.data.tier == 'free'
        && request.resource.data.tier_status == 'active'
        && request.resource.data.credits == 0
        && request.resource.data.created_at is timestamp
        && request.resource.data.updated_at is timestamp;

      allow update: if isOwner(uid)
        && onlyKeys(request.resource.data, [
             'uid', 'email', 'display_name',
             'tier', 'tier_status', 'credits',
             'preferences', 'created_at', 'updated_at'
           ])
        // Sin esta línea, "editar mi perfil" incluye "regalarme el plan de
        // pago y recargarme el saldo". No hace falta ningún exploit: basta
        // con que la regla no lo prohíba.
        && unchanged(['uid', 'created_at', 'tier', 'tier_status', 'credits'])
        && request.resource.data.updated_at is timestamp;

      allow delete: if false;
    }

Dos cosas de aquí me parecen las que más rentan.

La primera es hasOnly. Sin ella, la regla valida los campos que tú conoces e ignora en silencio los que no. Un cliente puede colar is_verified: true, o internal_flags, o cualquier cosa, y se guardará, porque tu regla nunca preguntó por ella. Con la lista cerrada, ese documento se rechaza entero: el cliente recibe un PERMISSION_DENIED ruidoso en vez de escribir un campo fantasma que nadie descubrirá hasta que una agregación empiece a devolver números raros.

La segunda es que la inmutabilidad de tier y credits no protege datos, protege privilegios. Si un campo del documento decide lo que su dueño puede hacer, su dueño no puede ser quien lo escribe. Esa frase se aplica sola en cuanto empiezas a mirar el esquema con ojos de atacante.

En un `update`, `request.resource.data` es el documento entero

Este es el primero de los tres bugs, y es el que más gente veo que se come.

En un create, request.resource.data es lo que manda el cliente. Intuitivo. En un update también parece que debería ser lo que manda el cliente, pero no: es el documento resultante ya fusionado, con todos los campos que ya estaban ahí y que esta escritura no toca.

Lo que eso implica en la práctica: si un campo lo escribe tu servidor y por eso no está en la lista blanca del create, tiene que estar sí o sí en la del update. Si no, cualquier actualización posterior de ese documento, aunque no roce ese campo, morirá contra tu propio hasOnly.

En mi ejemplo de avistamientos, coarse_cell es una celda geográfica aproximada que calcula un trigger del servidor a partir de la coordenada exacta, para poder hacer mapas de densidad sin exponer dónde está un nido. El cliente no la escribe nunca. Fíjate en la asimetría:

      match /sightings/{sightingId} {
        allow read: if isOwner(uid);

        allow create: if isOwner(uid)
          && onlyKeys(request.resource.data, [
               'id', 'owner_id', 'species_id', 'seen_at',
               'individuals', 'habitat', 'notes',
               'coords_sealed', 'created_at', 'updated_at'
             ])
          && request.resource.data.id == sightingId
          && request.resource.data.owner_id == uid
          && boundedString(request.resource.data.species_id, 1, 64)
          && request.resource.data.seen_at is timestamp
          && request.resource.data.individuals is int
          && request.resource.data.individuals >= 1
          && request.resource.data.individuals <= 10000
          // Texto libre sin tope = un documento de dos megas que te cuesta
          // dinero en CADA lectura que lo toque, para siempre.
          && boundedString(request.resource.data.notes, 0, 2000)
          && sealed(request.resource.data.coords_sealed)
          && request.resource.data.created_at is timestamp
          && request.resource.data.updated_at is timestamp;

        allow update: if isOwner(uid)
          // 'coarse_cell' NO está en el create (lo escribe el trigger), pero
          // SÍ tiene que estar aquí: en un update, request.resource.data es el
          // doc completo ya fusionado. Sin esta clave, cualquier edición de un
          // avistamiento ya procesado revienta contra este mismo hasOnly.
          && onlyKeys(request.resource.data, [
               'id', 'owner_id', 'species_id', 'seen_at',
               'individuals', 'habitat', 'notes',
               'coords_sealed', 'coarse_cell',
               'created_at', 'updated_at'
             ])
          && unchanged(['id', 'owner_id', 'created_at', 'coarse_cell'])
          && boundedString(request.resource.data.notes, 0, 2000)
          && sealed(request.resource.data.coords_sealed)
          && request.resource.data.updated_at is timestamp;

        allow delete: if isOwner(uid);
      }

Aparece en la lista blanca para poder pasar, y en unchanged para que el cliente no pueda tocarla. Las dos cosas, o no sirve de nada.

Este detalle tiene una consecuencia mayor que su propio bug: cada campo que añades al esquema te obliga a volver a las reglas. Es fricción real y la pagas en cada feature. También es lo que hace que un refactor descuidado se estrelle contra un PERMISSION_DENIED en el emulador en vez de contra un undefined is not a function en el móvil de alguien, seis meses después. Yo la considero mantenimiento, no impuesto.

Leer un campo que no existe deniega la escritura entera

Segundo bug, y este me tuvo mirando al cliente durante horas cuando el problema estaba en la regla.

Si tu regla evalúa request.resource.data.habitat in ['bosque', 'humedal'] y el documento entrante no trae habitat, la expresión no devuelve false. Lanza un error de evaluación. Y un error de evaluación en una regla se traduce a PERMISSION_DENIED, exactamente igual que una denegación legítima. Desde el cliente ves un permiso denegado que no tiene ningún sentido, y te pones a mirar la autenticación, que está perfecta.

Para todo campo opcional hay que guardar la comprobación:

          // `habitat` es opcional: hay avistamientos que solo registran especie
          // y hora. Sin este guardián, ese create legítimo se deniega por un
          // error de evaluación, no por falta de permisos.
          && (!('habitat' in request.resource.data)
              || request.resource.data.habitat in [
                   'bosque', 'humedal', 'costa', 'urbano', 'montana'
                 ])

Es feo y hay que repetirlo campo a campo. No he encontrado nada mejor. El patrón que uso para no volver a caer: si el cliente puede omitir el campo en alguna ruta de código, la regla lo envuelve. Siempre.

Un regex sin estructura es una validación decorativa

El tercero, y el que más me escoció, porque la regla existía, se leía bien y no servía para nada.

Los campos sensibles se cifran en el cliente antes de tocar la base de datos, y llegan como un token con formato conocido. La regla estaba para que un cliente con un bug no pudiera guardar texto en claro donde tenía que ir cifrado. La escribí así:

    // MAL: matches() evalúa la cadena completa, pero `.*` acepta cualquier
    // cosa que quepa en una línea. Esto valida el prefijo y nada más.
    function sealed(value) {
      return value is string && value.matches('box:1:.*');
    }

box:1:41.3874, 2.1686 pasa esa validación sin despeinarse. El prefijo estaba, la coordenada iba en claro, y las reglas decían que todo correcto. Lo que hacía falta era describir la estructura y el alfabeto, no el principio de la cadena:

    // Token cifrado en cliente: `box:1:<nonce_b64>:<ciphertext_b64>`.
    // El alfabeto base64 y las dos secciones son la validación de verdad; el
    // tope de tamaño evita que alguien use este campo como almacén gratis.
    function sealed(value) {
      return value is string
        && value.size() <= 4096
        && value.matches('box:1:[A-Za-z0-9+/=]+:[A-Za-z0-9+/=]+');
    }

La lección que me llevé no es sobre regex. Es que una validación que nunca has visto fallar no es una validación, es una decoración. Hasta que no escribí el test que intenta guardar box:1: seguido de basura y espera un rechazo, esa función era una mentira que se leía muy bien en la revisión.

Lo que decidí que las reglas no van a hacer

Hay una tentación fuerte, cuando descubres que puedes validar tanto, de intentar validarlo todo aquí. He acabado con una línea bastante clara de lo que no entra.

Nada que necesite estado. Cuántas exportaciones puede pedir alguien al mes, cuántas peticiones por hora tolera una cuenta, si un contador cuadra: eso es lógica con transacciones y reintentos, y vive en el servidor. Una regla se evalúa por documento y por escritura, sin memoria de la anterior.

Nada que dependa de otro documento, salvo excepción justificada. Puedes hacer get() dentro de una regla, y a veces hace falta. Pero cada get() se factura como una lectura más y se ejecuta en cada intento de escritura, incluidos los que van a fallar. Tengo exactamente uno en todo el archivo, y está ahí porque no había alternativa.

Nada sobre el significado. Una regla comprueba que un texto mide entre 0 y 2000 caracteres. No puede comprobar si ese texto es apropiado, si tiene sentido o si es lo que el usuario cree que escribió. Eso pertenece a otra capa, y confundirlas es cómodo y falso.

Lo que sí hago es estrechar el camino hasta que sea casi un ojo de cerradura. El caso que más me gusta es el de las operaciones largas. El cliente no ejecuta el trabajo ni escribe su resultado: solo deposita una solicitud inerte, y el servidor la recoge y mueve el estado con el Admin SDK, que se salta estas reglas por completo.

      match /export_jobs/{jobId} {
        allow read: if isOwner(uid);

        // El cliente solo puede dejar una solicitud parada en 'queued'. El
        // ciclo de vida (processing, done, failed) lo mueve el worker con el
        // Admin SDK, que no pasa por estas reglas. Así el cliente no puede
        // marcarse un trabajo como completado sin haberlo pagado ni ejecutado.
        allow create: if isOwner(uid)
          && onlyKeys(request.resource.data, [
               'id', 'owner_id', 'status',
               'range_from', 'range_to', 'created_at'
             ])
          && request.resource.data.id == jobId
          && request.resource.data.owner_id == uid
          && request.resource.data.status == 'queued'
          && request.resource.data.range_from is timestamp
          && request.resource.data.range_to is timestamp
          && request.resource.data.created_at is timestamp;

        allow update: if false;
        allow delete: if isOwner(uid);
      }

      // Material criptográfico del usuario. No hay ninguna vía por la que un
      // cliente lea esto: lo maneja solo el servidor.
      match /vault/{document=**} {
        allow read, write: if false;
      }

Que el Admin SDK ignore las reglas es la pieza que hace que todo lo anterior sea sostenible. Las reglas no tienen que ser expresivas, tienen que ser estrechas. Todo lo que no cabe en ellas se sube un piso, donde hay un lenguaje de programación de verdad.

Y una limitación que las reglas por sí solas no arreglan: verifican quién hace la petición, no desde dónde. Ahí es donde entra App Check, exigido en Firestore: un curl con un token de sesión robado, pero sin poder pasar la comprobación de dispositivo/app (reCAPTCHA v3 en web, Play Integrity o App Attest en nativo), se queda fuera antes de llegar siquiera a evaluar una regla.

Reglas que se ejecutan, no que se leen

Todo esto vive en un archivo declarativo que no compila contra nada, no tiene tipos y no falla hasta que un usuario le pega. La única forma de saber si dice lo que crees que dice es ejecutarlo.

@firebase/rules-unit-testing levanta el emulador y te deja lanzar operaciones como usuarios distintos. La suite tiene dos mitades, y la segunda es la que importa:

test('el dueño edita sus propias notas', async () => {
  const db = observerContext('obs_1').firestore();
  await assertSucceeds(
    updateDoc(doc(db, 'observers/obs_1/sightings/s1'), {
      notes: 'Dos ejemplares al amanecer',
      updated_at: serverTimestamp(),
    })
  );
});

test('nadie se regala el plan de pago editando su perfil', async () => {
  const db = observerContext('obs_1').firestore();
  await assertFails(
    updateDoc(doc(db, 'observers/obs_1'), {
      tier: 'pro',
      updated_at: serverTimestamp(),
    })
  );
});

test('un token cifrado mal formado no entra', async () => {
  const db = observerContext('obs_1').firestore();
  await assertFails(
    setDoc(doc(db, 'observers/obs_1/sightings/s2'), {
      ...validSighting('obs_1', 's2'),
      coords_sealed: 'box:1:41.3874, 2.1686',
    })
  );
});

Con una trampa que me parece importante y que casi nunca se menciona: assertFails pasa por el motivo equivocado con muchísima facilidad. Si construyes el documento de prueba a mano y se te olvida un campo obligatorio, el test pasa en verde porque la escritura falló, pero falló por la forma del documento, no por el permiso que creías estar probando. La regla que querías verificar puede estar rota y tu suite seguirá contenta.

Por eso todos mis casos negativos parten de un documento válido y le cambian una sola cosa, la que se está probando. Un helper que genera el documento correcto y un spread encima. Si el caso positivo equivalente no pasa en verde, el negativo no demuestra nada.

Dónde estoy

Nada de esto es sofisticado. Es un archivo largo, repetitivo y aburrido, que hay que tocar cada vez que cambia el esquema y que no le luce a nadie. A cambio, un cliente comprometido, un refactor mío mal pensado o un formulario con un bug producen un error ruidoso en vez de un dato podrido.

Sigue habiendo huecos que conozco y no he cerrado. El get() que tengo dentro de una regla me cuesta una lectura y algún día será un problema de coste. Y aunque tengo App Check exigido en Firestore (reduce la superficie de scripts sueltos con un token robado, no la cierra del todo), las reglas siguen sin poder distinguir a un usuario legítimo de su propia sesión robada desde su propia app.

Si trabajas con Firestore y crees que el catch-all del final de tu archivo te está protegiendo de algo, revisa qué hay por encima. Es el rato mejor invertido de esta semana. Y si te apetece decirme dónde me estoy equivocando, la parte más útil de escribir esto es justo esa.

Cómo pensamos el cifrado de PII en una app Ionic + Angular, para cumplir el RGPD y la LOPD-GDD

Daniel Morfa Vega — Sun, 23 Aug 2026 18:27:04 +0000

Envelope encryption con clave por usuario, qué se cifra y qué no, cómo lo puso a prueba una auditoría externa, y el incidente de rendimiento que provocó nuestro propio hardening de seguridad.

Montaste tu app con IA rápido: le pides unos datos al usuario, llamas al modelo, guardas el resultado en la base de datos y a producción. Cómodo, sin complicaciones.

Hasta que un día miras bien qué estás guardando.

En Cuentopia generamos cuentos personalizados para niños. Para personalizar, un padre nos cuenta cómo es su peque: su carácter, qué le da miedo, qué está pasando en casa. El modelo no improvisa sobre la marcha: se apoya en un marco de criterios clínicos y pedagógicos para decidir cómo abordar cada situación, y luego lo reescribe todo en prosa. Visto de golpe, lo que teníamos en la base de datos era el diario emocional de un montón de menores.

El RGPD lo trata como categoría especialmente protegida. El sentido común, también. ¿Y si se filtra la base de datos? ¿Y un backup mal guardado? ¿Y un acceso indebido con privilegios de admin?

Relájate (bueno, primero asústate un poco; luego relájate). Te voy a contar cómo pensamos el cifrado en reposo en serio: una arquitectura de tipo envelope encryption, con una clave maestra que no sale nunca de Cloud KMS (Google Cloud) y una clave por usuario que cifra los campos sensibles antes de que toquen la base de datos.

Un aviso antes de seguir: te cuento el criterio y las decisiones, no el plano. No vas a encontrar aquí nombres de recursos, rutas de repositorio, ni el detalle exacto que le serviría de receta a alguien con ganas de probar suerte con nuestros datos. Y porque la seguridad honesta se cuenta entera, también te cuento dónde decidimos no llegar y por qué.

✨ Promesa: al terminar vas a entender, con criterio real de producto, cómo una familia sin ser expertos en cripto se planteó cifrar datos de menores, y por qué ciertas decisiones muy concretas no se hacen públicas nunca, ni en el artículo más honesto.

El mapa

Lo construimos de dentro hacia fuera: primero el núcleo del cifrado, después una auditoría adversarial que nos bajó los humos y forzó varios cambios de endurecimiento, y por último, porque toda decisión de seguridad tiene una factura escondida, un incidente de rendimiento que nos costó un buen susto. Esta es esa historia, contada en fases, no en versiones ni en commits.

Diseño y cifrado base: arquitectura envelope, clave por usuario, primeros campos cifrados.
Auditoría y hardening: pentest adversarial, cierre de hallazgos, borrado con crypto-shredding.
Ajuste de rendimiento: un cambio de seguridad correcto que rompió la experiencia, y su arreglo.

Una aclaración antes de seguir, porque importa: hicimos todo este proceso (diseño, auditoría, endurecimiento) con Cuentopia en beta muy temprana, con mi propia cuenta como único usuario real en la base de datos. Ningún dato de ninguna familia estuvo nunca ahí sin este cifrado; lo construimos antes de abrir la puerta a nadie más, precisamente porque hacerlo después, con usuarios reales y datos ya en producción, habría sido mucho más caro y mucho más arriesgado. Si quieres ver cómo se lo contamos a las familias, sin la jerga de este artículo, ahí está la versión pensada para ellas: cuentopia.es/tu-confianza.

Y ya que estamos, crédito donde toca: todo esto corre sobre Firebase: Firestore para los datos, Cloud Functions para la lógica de servidor, y Google Cloud KMS para la clave maestra. No reinventamos gestión de claves: nos apoyamos en servicios gestionados que ya audita gente con más recursos que nosotros.

TL;DR

Cuentopia genera cuentos personalizados con IA a partir de datos sensibles de menores. La solución: cifrado de campos en reposo con envelope encryption. Una clave maestra vive en Cloud KMS, de Google Cloud, y nunca sale de ahí; cada usuario tiene su propia clave de datos, que la maestra envuelve y que se guarda cifrada junto a sus datos en Firestore. El cliente pide su clave una vez por sesión, la usa en memoria para cifrar y descifrar campo a campo, y Firestore solo ve texto cifrado.

Qué ciframos y qué no (y el criterio que lo gobierna)

Antes de tocar criptografía hubo una decisión de producto, refinada en una sesión de grilling del diseño:

Se cifra: el perfil del peque (nombre, rasgos, lo que le preocupa, lo que le hace ilusión), el contenido de los cuentos privados, el contexto libre que escribe el adulto al pedir un cuento a medida, y las notas de los "momentos personalizados" que una familia documenta.
No se cifra: los cuentos públicos del catálogo, que no contienen datos reales de nadie: usan personajes ficticios.

De ahí nace el criterio que gobierna todo el sistema:

Público ⇒ texto plano. Privado ⇒ cifrado. Un remix de un cuento público entra por el canal privado, así que nace cifrado.

Perfil del peque: lo cifra el cliente, al guardar.
Cuentos privados: los cifra el propio motor de generación, del lado servidor.
Contexto libre de la petición: lo cifra el cliente, al guardar.
Notas y momentos personalizados: las cifra el cliente, al guardar.

Este criterio es el que permite que la lectura sea segura por defecto: si un documento no lleva metadata de cifrado, se asume texto plano y pasa tal cual. Así conviven, sin fricción, los cuentos públicos y los privados.

Envelope encryption, sin misterio

El esquema es de libro, en tres niveles:

Cloud KMS (Google Cloud) guarda la clave maestra: nunca sale de ahí.
La clave maestra envuelve y desenvuelve la clave de datos, por usuario, que se guarda cifrada junto a los datos de cada cuenta.
Esa clave de datos cifra y descifra los campos sensibles, campo a campo: la base de datos solo ve texto cifrado.

Por qué envelope y no cifrar cada campo directo contra el gestor de claves: un servicio gestionado de claves cobra y limita por operación, y no quieres mandarle cada campo del formulario. Con envelope, el gestor solo interviene una vez por sesión (para envolver o desenvolver la clave de datos); el cifrado masivo lo hace el propio cliente, en local.

Dos decisiones de diseño que importan, sin entrar en el formato exacto:

Cada valor cifrado queda atado a quién es su dueño y a qué campo pertenece. Mover un valor cifrado de un campo a otro, o de una cuenta a otra, rompe la verificación. No es un detalle menor: convierte cualquier intento de "recombinar" datos cifrados en un fallo ruidoso, no en una fuga silenciosa.
El formato de cifrado lleva versión desde el primer día. Eso deja la puerta abierta a rotar el esquema completo sin tener que rediseñarlo sobre la marcha.

🩺 Moraleja: envelope > cifrar directo contra el gestor de claves. El gestor interviene una vez por sesión; el trabajo pesado lo hace el cliente, y te cuesta céntimos.

La clave de cada usuario: caché, condiciones de carrera y quién puede pedirla

El cliente nunca ve la clave maestra. Pide su clave de datos una única vez por sesión, a una función serverless de Firebase Cloud Functions, y la mantiene en memoria, en un formato que no se puede exportar ni volcar. Esa clave se cachea localmente. Y ahí aparece una condición de carrera con la que merece la pena tener cuidado: si el usuario cierra sesión justo mientras la petición de clave sigue en vuelo, hay que descartar el resultado cuando llegue. Cachearlo de todos modos asociaría la clave del usuario anterior a la sesión nueva. Es el tipo de bug que no rompe nada en desarrollo y sí en producción, con dos pestañas abiertas.

Del lado servidor, la generación de esa clave por usuario es idempotente: la primera vez se genera, se envuelve con la clave maestra y se persiste; cualquier intento posterior devuelve siempre la misma, incluso si dos dispositivos intentan generarla a la vez en un primer login simultáneo: la que gana la carrera es la única verdad, y el "perdedor" recibe esa misma clave en lugar de crear la suya.

Y aplicamos fail-closed como principio, no como parche puntual: ante cualquier ambigüedad de configuración entre entornos, el sistema prefiere fallar de forma ruidosa antes que degradarse en silencio hacia un camino menos estricto.

Y el acceso: la clave envuelta de cada usuario vive en una parte de la base de datos que el cliente nunca puede leer directamente, solo el código que corre con privilegios de servidor. Esa separación es la que, más adelante, hace posible el borrado de cuentas de verdad (ver más abajo).

Que el servidor no se fíe del cliente

El cifrado no se confía solo al cliente: las reglas de acceso de Firestore rechazan cualquier escritura que no tenga la forma exacta de un valor cifrado completo, de principio a fin: nada de subcadenas sueltas ni de texto en claro con un prefijo que lo disimule. Si el cliente tiene un bug y trata de escribir algo sin cifrar, el servidor lo rechaza antes de que llegue a guardarse.

🩺 Moraleja: si el cliente puede equivocarse y escribir en claro, se equivocará. Haz que el servidor lo rechace. Las reglas de acceso son parte del esquema de cifrado, no un añadido.

El pentest que nos bajó los humos

Tras el rollout inicial nos dejamos auditar por fuera, con un enfoque adversarial: reglas de acceso, criptografía, el motor de generación y el tratamiento general de datos personales. El veredicto fue tranquilizador en lo esencial:

El núcleo aguanta. El aislamiento entre cuentas es sólido: la clave de un usuario es inaccesible para otro, y eso no depende de nada que el cliente pueda manipular. No es cifrado de extremo a extremo: quien consiguiera robar una sesión activa y superar las comprobaciones del cliente, podría obtener la clave desde el servidor. Los problemas reales estaban en canales laterales y en endurecer bordes, no en el núcleo.

Aclarando esa frase, porque es la que más se malinterpreta: "no es E2E" no significa que los datos vayan sin cifrar. Significa que la clave para descifrarlos no vive solo en el dispositivo de cada familia, como en una app de mensajería cifrada de verdad. Vive también en nuestra infraestructura (Cloud KMS y Firestore), porque es el propio servidor quien la genera y la entrega bajo demanda a quien se autentique correctamente. Protege frente a una fuga de base de datos, un backup robado o un acceso indebido a los datos en reposo. No protege frente a un compromiso del propio backend de Cuentopia: ahí seguimos siendo, técnicamente, un punto de confianza.

¿Por qué no fuimos a por un E2E de verdad? Porque parte de lo que ciframos lo escribe el propio motor de generación en el servidor: el cuento en sí. Un esquema E2E puro, donde ni el servidor puede descifrar nunca nada, es incompatible con tener una IA que necesita trabajar con ese contenido para escribirlo. Con esa limitación por delante, elegimos lo que sí podíamos ofrecer con solidez: aislamiento fuerte entre cuentas (la clave de una familia es inaccesible para otra, y esa sí es una garantía dura) y datos cifrados en todo momento en reposo.

Para cerrar ese hueco de verdad haría falta mover el procesamiento del agente a un entorno de confidential computing (enclaves con atestación remota, donde ni nuestra propia infraestructura pueda inspeccionar la memoria mientras se genera el cuento). No lo tenemos hoy; queda documentado como posible siguiente paso, no como excusa.

Lo que se corrigió, por categorías:

Se ajustó la validación de formato para que fuera más estricta: la versión anterior, sin querer, dejaba colar algo parecido a texto en claro si llevaba el prefijo correcto delante.
Se exigió una comprobación de integridad de la app más fuerte en la operación más sensible de todas (la que entrega la clave), cerrando así un camino de ataque que solo dependía de robar una sesión.
Se encontró y cerró una fuga activa: un registro de depuración que, sin darnos cuenta, se llevaba datos ya descifrados a un sistema de logs que no tenía ningún motivo para verlos.
Se reforzó el principio de fail-closed descrito arriba, cerrando un caso límite de configuración que podía dar lugar a ambigüedad.
En vez de cifrar las imágenes de portada, se atacó la raíz del problema: se cambió cómo se le pide la imagen al modelo, para que ya no describa un retrato reconocible del peque.

⚠️ El bug más feo no era de criptografía: era un registro de depuración que se llevaba datos descifrados a un sistema que no pintaba nada ahí. Revisa tus logs. De verdad.

Y dos cambios que cierran obligaciones de RGPD:

Borrado de cuenta con crypto-shredding. Borrar una cuenta borra, entre otras cosas, la clave de datos de esa persona. Sin esa clave, cualquier resto cifrado que pudiera quedar en una copia de seguridad es matemáticamente irrecuperable: destruir la clave equivale a destruir el dato, sin tener que perseguir cada copia una por una.
Cierre de un hueco de texto en claro residual en uno de los tipos de nota personal, que se nos había quedado fuera del primer barrido.

Cuando el hardening te rompe el producto

Exigir una comprobación de integridad más fuerte en la operación que entrega la clave parecía la decisión correcta. Lo era. Y aun así, rompió el producto.

El síntoma me volvió loco un rato: la función respondía rápido y sin un solo error en sus registros. Pero abrir la ficha de un cuento privado se quedaba cargando casi un minuto.

La trampa estaba fuera de la función. Si pides la clave de forma perezosa, justo al abrir el cuento, y el token que certifica que la petición viene de una app legítima todavía no se ha generado, la llamada se rechaza antes de llegar a entrar en la función. Por eso sus registros estaban limpios: el problema nunca llegaba hasta ahí. Y la pantalla, mientras tanto, reintentaba en bucle hasta agotar su margen de espera.

La cripto no tenía la culpa. La tenía la carrera entre pedir la clave y que ese token de integridad estuviera listo.

El arreglo fue dejar de pedir la clave en el peor momento posible: la calentamos al hacer login, mientras el usuario todavía está en la pantalla de inicio, para que ya esté disponible cuando abra el primer cuento. Es un intento de mejor esfuerzo, con reintentos; si falla, la petición perezosa de siempre sigue actuando de red de seguridad.

🩺 Moraleja: un cambio de seguridad puede ser correcto y aun así arruinar la experiencia. El hardening y el rendimiento se diseñan juntos, o te enteras en producción.

Qué no ciframos, con criterio

Buena parte del trabajo "invisible" fue alinear la residencia de los datos: la base de datos, el gestor de claves, el código que toca estos datos y los modelos de IA que generan los cuentos viven todos dentro de la Unión Europea, backups incluidos.

Y un sistema honesto documenta lo que no hace:

El valor cifrado no lleva el identificador del documento al que pertenece, solo el dueño y el campo. En teoría, alguien que ya tuviera la clave de una cuenta podría copiar un valor cifrado entre dos documentos suyos del mismo campo. Lo evaluamos y lo deferimos con criterio: quien ya tiene esa clave puede reescribir cualquier cosa de todos modos, así que el riesgo añadido es bajo frente al coste de rehacer el esquema y volver a cifrar todos los datos existentes. Documentado, no implementado.
Las imágenes de portada no van cifradas. Decisión deliberada: en vez de cifrar la imagen, se eliminó el dato personal de su origen: el modelo ya no genera un retrato reconocible del peque, sino un personaje estilizado y ficticio.
Los datos del adulto (correo, nombre de la cuenta, datos de facturación) son otro nivel de sensibilidad y no entran en este esquema; cifrarlos rompería la integración con el proveedor de pagos. Decisión de producto, no descuido.
Un bloqueo biométrico de la app se evaluó y se aparcó: la versión criptográficamente sólida no compensaba (no cierra el hueco de "sesión robada" y arriesga pérdida de acceso si alguien olvida su PIN); una versión más simple, solo para bloquear la pantalla sin tocar las claves, queda como posible mejora futura.
La rotación de la clave maestra queda fuera de alcance por ahora: el formato versionado deja la puerta abierta para el día que haga falta.

🩺 Moraleja: un sistema honesto enumera lo que NO hace. "No es cifrado de extremo a extremo" no es una vergüenza; es una decisión de diseño que se escribe.

Qué te llevas (y qué nos llevamos)

Envelope encryption es el patrón correcto para datos personales en reposo en una app móvil/web con backend gestionado: el servicio de claves guarda la maestra, el cliente hace el trabajo masivo, y el coste es de céntimos.
Atar cada valor cifrado a su dueño y su campo vale oro. Convierte cualquier intento de mover datos cifrados de sitio en un fallo de verificación, no en una fuga silenciosa.
Las reglas de acceso son parte del esquema de cifrado, no un añadido: rechazar texto en claro en el servidor es lo que hace que un bug del cliente no se convierta en una fuga.
Crypto-shredding hace operativo el "derecho al olvido". Borrar una clave es instantáneo y alcanza incluso las copias de seguridad; borrar datos a mano, no.
Un sistema de cifrado honesto enumera su modelo de amenaza y sus huecos. "No es de extremo a extremo" no es una vergüenza: es una decisión de diseño que hay que escribir.
El hardening tiene secuelas. Una comprobación de seguridad correcta puede, aun así, dejar el producto colgado casi un minuto. Seguridad y rendimiento se prueban juntos.

(Cómo piensa el agente que escribe estos cuentos, con qué criterio decide qué contar y cómo, para que no sea una tirada de dados de un modelo de lenguaje, es tema para otro artículo.)

Cifrar la PII de los peques no era "una feature de seguridad" más en el backlog: era ponerle un seguro de salud al producto y a la confianza de quien lo usa. Y costó céntimos al mes.

Checklist de mentalidad (cripto de PII en serio):

Envelope, no cifrado directo contra el gestor de claves. La clave maestra no sale de ahí; el cifrado masivo lo hace el cliente. Céntimos, no facturas.
Ata cada valor cifrado a su dueño y su campo. Es prácticamente gratis y convierte cualquier swap de datos en un fallo de verificación.
Que el servidor rechace el texto en claro. Las reglas de acceso son parte del esquema, no un adorno.
Crypto-shredding = derecho al olvido operativo. Borrar una clave es instantáneo y alcanza las copias de seguridad. Borrar datos a mano, no.
Enumera tus huecos. "No es de extremo a extremo" escrito no es debilidad: es la diferencia entre un sistema seguro y uno opaco.
Prueba seguridad y rendimiento juntos. Una comprobación de integridad correcta te puede dejar el producto colgado casi un minuto. Pregúntame cómo lo sé.

Y una última cosa. Nadie nos obligó a esto: ni un cliente, ni una auditoría externa que nos llegara de sorpresa. Pero si vas a pedirle a una familia que te cuente lo más íntimo de su hijo, lo mínimo es tratarlo como lo que es. Monta tu envelope, ata tus datos cifrados a su dueño, destruye la llave al borrar la cuenta… y duerme tranquilo sabiendo que lo de tus usuarios está cifrado de verdad. Si le encuentras un fallo a lo nuestro, escríbeme: la versión honesta de la seguridad incluye que alguien de fuera te diga dónde te equivocaste. Tu yo del futuro, y el padre que confió en ti, te lo agradecerán.