Revise sus reglas de seguridad de Firebase con 26 errores comunes
Pegue sus reglas de Firestore, de Firebase Storage o de Realtime Database. El revisor lee el texto y muestra qué rutas dejan leer o escribir a cualquiera.
Resultado
Este es un análisis estático del texto pegado. No ve custom claims, App Check, la forma de los datos ni reglas que nunca se publicaron; la nota cubre solo lo que las 26 comprobaciones pueden leer.
Lo que esta revisión no puede ver
El revisor solo lee el texto pegado. No ve custom claims, App Check, la forma de sus datos ni reglas que nunca se publicaron, así que un resultado limpio no significa que el proyecto sea seguro.
Las 26 comprobaciones
| Comprobación | ID | Servicio | Gravedad |
|---|---|---|---|
| Cualquiera puede escribir en Firestore | fs-open-write | Firestore | Crítica |
| Cualquiera puede leer de Firestore | fs-open-read | Firestore | Media |
| Un match con comodín recursivo está abierto | fs-recursive-wildcard-open | Firestore | Crítica |
| Reglas del modo de prueba con fecha de caducidad | fs-test-mode-expiry | Firestore | Crítica |
| Cualquier usuario con sesión iniciada puede escribir | fs-auth-only-write | Firestore | Alta |
| Cualquier usuario con sesión iniciada puede leer | fs-auth-only-read | Firestore | Media |
| Se confía en el email sin email_verified | fs-email-unverified | Firestore | Media |
| Rol leído de los datos de la solicitud | fs-role-from-request | Firestore | Alta |
| Un comodín amplio oculta reglas más estrictas | fs-wildcard-shadow | Firestore | Alta |
| Los usuarios pueden escribir su propio rol (heurística) | fs-self-role-write | Firestore | Alta |
| La escritura acepta cualquier campo (heurística) | fs-write-no-field-guard | Firestore | Media |
| read no está dividido en get y list | fs-read-not-split | Firestore | Info |
| Sin denegación explícita por defecto | fs-no-default-deny | Firestore | Info |
| No se pudieron leer las reglas de Firestore | fs-parse-error | Firestore | Info |
| Cualquiera puede leer los archivos de Storage | st-open-read | Storage | Media |
| Cualquiera puede escribir en Storage | st-open-write | Storage | Crítica |
| El match {allPaths=**} está abierto | st-recursive-wildcard-open | Storage | Crítica |
| Cualquier usuario con sesión iniciada puede escribir en Storage | st-auth-only-write | Storage | Alta |
| No se pudieron leer las reglas de Storage | st-parse-error | Storage | Info |
| Cualquiera puede leer toda la base de datos | db-root-read-open | Realtime Database | Crítica |
| Cualquiera puede escribir en toda la base de datos | db-root-write-open | Realtime Database | Crítica |
| Cualquiera puede leer un nodo | db-open-read | Realtime Database | Media |
| Cualquiera puede escribir en un nodo | db-open-write | Realtime Database | Alta |
| El padre anula una regla del hijo | db-cascade-override | Realtime Database | Alta |
| Cualquier usuario con sesión iniciada puede leer o escribir toda la base de datos | db-auth-only-root | Realtime Database | Alta |
| No se pudieron leer las reglas de Realtime Database | db-parse-error | Realtime Database | Info |
Preguntas
¿Qué revisa el revisor de reglas de Firebase?
Lee las reglas de seguridad de Firebase que pega para Firestore, Cloud Storage y Realtime Database y busca reglas que dejan leer o escribir a cualquiera, reglas que solo exigen un usuario con sesión iniciada, confianza en datos del cliente y patrones parecidos.
¿Se guarda el texto de mis reglas?
No. Las reglas se procesan en memoria en la red de Cloudflare y se descartan en cuanto se envía la respuesta. No se guarda ni se registra nada junto con el texto.
¿Cuánto puedo pegar?
Hasta 48,000 caracteres en total entre los tres campos. Si sus reglas son más largas, pegue la parte que quiere revisar.
¿Por qué una regla de lectura pública puede estar bien?
Algunos datos son públicos a propósito, como un catálogo de productos o las entradas de un blog. En Firestore y Storage, el revisor cuenta una lectura sin condición como un problema medio y resta 10 puntos, porque no puede saber si los datos son privados. Si los datos son públicos a propósito, puede aceptar ese coste. Solo en la raíz de Realtime Database valora una lectura abierta como más grave.
¿Qué son las reglas del modo de prueba?
Cuando crea una base de datos de Firestore en modo de prueba, la consola escribe una regla que permite todo hasta una fecha, con request.time. Hasta esa fecha cualquiera puede leer y escribir; después se deniega todo y la app deja de funcionar. Sustitúyala por condiciones reales antes del lanzamiento.
¿Cómo se heredan las reglas de Realtime Database?
En Realtime Database, una regla que concede acceso se aplica a todo lo que hay debajo, y un hijo no puede retirarla. Una regla más estricta en un hijo bajo un padre permisivo nunca se aplica, por eso el revisor la señala.
¿Qué significa la nota?
Resume solo lo que las comprobaciones pueden leer en el texto pegado: una puntuación de 100 menos una penalización por cada comprobación fallida, fijada por el problema más grave que esa comprobación encontró, y cualquier problema crítico da F. Un punto medio también puede ser una heurística que le pide revisar a mano, porque el texto por sí solo no muestra si es un problema real. Una A no demuestra que el proyecto sea seguro, porque los custom claims, App Check y los propios datos quedan fuera de su alcance.