Sigue estos lineamientos para mantener seguros tus recursos de Firebase y los datos de los usuarios. No todos los elementos se aplicarán siempre a tus requisitos, pero tenlos en cuenta cuando desarrolles la app.
Evita el tráfico abusivo
Configura la supervisión y las alertas para los servicios de backend
Para detectar tráfico abusivo, como ataques de denegación del servicio (DoS), configura la supervisión y las alertas de Cloud Firestore, Realtime Database, Cloud Storage y Hosting.
Si sospechas que tu aplicación está siendo atacada, comunícate con el equipo de asistencia lo antes posible para informarle lo que sucede.
Habilita la Verificación de aplicaciones
Para garantizar que solo tus apps puedan acceder a los servicios de backend, habilita la Verificación de aplicaciones en todos los servicios que la admitan.
Configura tus Cloud Functions a fin de ajustar la escala para lidiar con el tráfico normal
Cloud Functions se escala automáticamente para satisfacer las demandas de tu app, pero en el caso de un ataque, esto puede causar que recibas una gran factura. Para evitar que suceda, puedes limitar la cantidad de instancias simultáneas de una función según el tráfico normal de la app.
Configura alertas para recibir notificaciones cuando los límites estén a punto de alcanzarse
Si tu servicio tiene aumentos de solicitudes, por lo general, se activan las cuotas y limitan automáticamente el tráfico a la aplicación. Asegúrate de supervisar el Panel de uso y facturación, pero también puedes configurar alertas de presupuesto en tu proyecto para recibir notificaciones cuando el uso de recursos exceda lo esperado.
Evita generar DoS: prueba las funciones localmente con los emuladores.
Puede ser fácil generar una DoS para tu aplicación de forma accidental mientras desarrollas Cloud Functions. Por ejemplo, puedes crear un bucle de activación y escritura infinito. Para evitar que estos errores afecten los servicios en ejecución, realiza el desarrollo con Firebase Emulator Suite.
(Y si generas accidentalmente una DoS, anula la implementación de tu función con solo quitarla
de index.js y, luego, ejecutar
Cuando la capacidad de respuesta en tiempo real es menos importante, estructura las funciones de manera defensiva
Si no necesitas presentar el resultado de una función en tiempo real, puedes mitigar el tráfico abusivo mediante el procesamiento de los resultados en lotes. Para ello, publica los resultados en un tema de Pub/Sub y procesa los resultados en intervalos regulares con una función programada.
Información sobre las claves de API
Las claves de API de los servicios de Firebase no son secretas
Firebase usa las claves de API solo para que los servicios de Firebase identifiquen el proyecto de Firebase de tu app y no para controlar el acceso a los datos de Cloud Storage o la base de datos, lo que se hace con las reglas de seguridad de Firebase. Por este motivo, no necesitas tratar las claves de API para servicios de Firebase como secretos y puedes incorporarlas de forma segura en el código del cliente. Obtén más información sobre las claves de API para Firebase.
Configuración del alcance de la clave de API
Como medida de seguridad adicional contra un atacante que intenta usar tu clave de API para falsificar solicitudes, puedes crear claves de API limitadas a los clientes de tu aplicación.
Mantén las claves de servidor de FCM en secreto
A diferencia de las claves de API para los servicios de Firebase, las claves de servidor de FCM (que usa la API de HTTP para FCM heredado) son sensibles y deben mantenerse en secreto.
Mantén las claves de cuentas de servicio en secreto
A diferencia de las claves de API para los servicios de Firebase, las claves privadas de cuentas de servicio (que usa el SDK de Admin) son sensibles y deben mantenerse en secreto.
Reglas de seguridad
Inicializa reglas en modo de producción o bloqueado
Cuando configures Cloud Firestore, Realtime Database y Cloud Storage, inicializa las reglas de seguridad para denegar todo el acceso de forma predeterminada y agrega reglas que otorguen acceso a recursos específicos a medida que desarrollas tu app.
Este es uno de los parámetros de configuración predeterminados para instancias nuevas de Cloud Firestore (modo de producción) y Realtime Database (modo bloqueado). Elige esta opción cuando configures una instancia de base de datos nueva.
En Cloud Storage, comienza con una configuración de reglas de seguridad, como la siguiente:
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if false;
}
}
}
Las reglas de seguridad son un esquema; agrega reglas cuando incluyas documentos
No escribas reglas de seguridad después de escribir tu app, como un tipo de tarea previa al lanzamiento. En su lugar, escribe reglas de seguridad a medida que escribes la app y trátalas como un esquema de base de datos, cada vez que debas usar un nuevo tipo de documento o estructura de ruta de acceso, primero escribe su regla de seguridad.
Realiza pruebas de unidades en las reglas de seguridad con Emulator Suite. Agrégalas a CI
Para asegurarte de que las reglas de seguridad se mantengan al día con el desarrollo de tu app, realiza pruebas de unidades con Firebase Emulator Suite y agrega estas pruebas a la canalización de CI. Consulta estas guías de Cloud Firestore y Realtime Database.
Authentication
Autenticación personalizada: crea JWT a partir de un entorno de confianza (del servidor)
Si ya tienes un sistema de acceso seguro, ya sea un sistema personalizado o un servicio de terceros, puedes usarlo para la autenticación con servicios de Firebase. Crea JWT personalizados a partir de un entorno de confianza y, luego, pasa los tokens a tu cliente, que usa el token para autenticarse (iOS+, Android, Web, Unity y C++).
Para ver un ejemplo de cómo usar la autenticación personalizada con un proveedor externo, consulta la entrada de blog Authenticate with Firebase using Okta.
Autenticación administrada: los proveedores de OAuth 2.0 son los más seguros
Si usas las funciones de autenticación administrada de Firebase, las opciones del proveedor de OAuth 2.0 o de OpenID Connect (Google, Facebook, etc.) son las más seguras. Si es posible, deberías admitir uno o más de estos proveedores (según tu base de usuarios).
Autenticación mediante correo electrónico y contraseña: establece una cuota estricta para el extremo de acceso a fin de evitar ataques de fuerza bruta
Si usas el servicio de autenticación administrada mediante correo electrónico y contraseña de Firebase, ajusta la cuota
predeterminada de los extremos identitytoolkit.googleapis.com para evitar ataques de
fuerza bruta. Puedes hacerlo desde la página de la API en la consola de Google Cloud.
Autenticación con correo electrónico y contraseña: Habilita la protección de enumeración de correo electrónico
Si usas el servicio de autenticación administrada con correo electrónico y contraseña de Firebase, habilita la protección de enumeración de correo electrónico si quieres evitar que usuarios maliciosos abusen de los extremos de autenticación de tu proyecto para adivinar los nombres de las cuentas.
Actualiza a Cloud Identity Platform para usar la autenticación de varios factores
Si deseas obtener mayor seguridad durante el acceso, actualiza a Cloud Identity Platform para agregar compatibilidad con la autenticación de varios factores. El código de Firebase Authentication existente seguirá funcionando después de la actualización.
Autenticación anónima
Utiliza la autenticación anónima solo para preparar la integración
Usa la autenticación anónima solo para guardar el estado básico de los usuarios antes de que accedan. La autenticación anónima no reemplaza el acceso de los usuarios.
Cambia los usuarios a otro método de acceso si quieren conservar sus datos cuando pierdan el teléfono
Los datos de autenticación anónima no se conservarán si el usuario borra el almacenamiento local o cambia de dispositivo. Si necesitas conservar datos no solo en los reinicios de la app en un único dispositivo, cambia al usuario a una cuenta permanente.
Usa reglas de seguridad que requieran que los usuarios se hayan cambiado a un proveedor de acceso o que hayan verificado su correo electrónico
Cualquier persona puede crear una cuenta anónima en tu proyecto. Con esta información en mente, protege todos los datos no públicos con reglas de seguridad que requieran métodos de acceso específicos o direcciones de correo electrónico verificadas.
Por ejemplo:
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
Administración del entorno
Configura proyectos de desarrollo y de etapa de pruebas
Configura proyectos de Firebase independientes para el desarrollo, la etapa de pruebas y la producción. No combines el código de cliente en la producción hasta que se pruebe en el proyecto de etapa de pruebas.
Limita el acceso del equipo a los datos de producción
Si trabajas con un equipo más grande, puedes mitigar las consecuencias de los errores y los incumplimientos limitando el acceso a los datos de producción con funciones predefinidas o funciones de IAM personalizadas.
Si tu equipo usa Emulator Suite para el desarrollo, es posible que no necesites otorgar un acceso más amplio al proyecto de producción.
Administración de las bibliotecas
Presta atención a los encargados de mantenimiento nuevos o las faltas de ortografía de las bibliotecas.
Cuando agregues bibliotecas a tu proyecto, presta mucha atención a su nombre y a sus encargados de mantenimiento. Una biblioteca con un nombre similar al de la que intentas instalar podría contener código malicioso.
No actualices bibliotecas si no comprendes los cambios
Revisa los registros de cambios de las bibliotecas que usas antes de realizar la actualización. Asegúrate de que la actualización agregue valor y verifica que el encargado de mantenimiento aún sea alguien de confianza.
Instala bibliotecas de perro guardián como dependencias de desarrollo o prueba
Usa una biblioteca como Snyk para analizar tu proyecto en busca de dependencias inseguras.
Configura la supervisión de Functions; revísala después de realizar actualizaciones en la biblioteca
Si usas el SDK del registrador de Cloud Functions, puedes supervisar y recibir alertas de comportamiento inusual, incluido el comportamiento causado por las actualizaciones de la biblioteca.
Seguridad de Cloud Functions
Nunca coloques información sensible en las variables de entorno de Cloud Functions
A menudo, en una app de Node.js autoalojada, usarás variables de entorno para contener la información sensible, como claves privadas. No lo hagas en Cloud Functions. Dado que Cloud Functions reutiliza los entornos entre invocaciones de funciones, la información sensible no se debe almacenar en el entorno.
- Para almacenar las claves de API de Firebase, que no son secretas, solo incorpóralas en el código.
- Si usas el SDK de Firebase Admin en una función de Cloud Functions, no es necesario que proporciones de manera explícita las credenciales de la cuenta de servicio, ya que el SDK puede adquirirlas de forma automática durante la inicialización.
- Si llamas a las API de Google y Google Cloud que requieren credenciales de la cuenta de servicio, la biblioteca de Google Auth para Node.js puede obtenerlas de las credenciales predeterminadas de la aplicación, que se propagan automáticamente en Cloud Functions.
- Si quieres que las claves privadas y las credenciales de servicios que no son de Google estén disponibles para Cloud Functions, usa Cloud Secret Manager.
Encripta la información sensible
Si no puedes evitar pasar información sensible a la función de Cloud Functions, debes crear tu propia solución personalizada para encriptar la información.
Las funciones simples son más seguras. Si necesitas complejidad, considera usar Cloud Run
Intenta que tus funciones de Cloud Functions sean lo más sencillas y comprensibles posible. A menudo, la complejidad de las funciones puede generar errores difíciles de detectar o comportamientos inesperados.
Si necesitas configuraciones complejas de entorno o lógica, se recomienda usar Cloud Run en lugar de Cloud Functions.