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.
