Para mantener seguros sus recursos de Firebase y los datos de sus usuarios, siga estas pautas. No todos los elementos se aplicarán necesariamente a sus requisitos, pero téngalos en cuenta a medida que desarrolla su aplicación.
Evita el tráfico abusivo
Configurar la supervisión y las alertas para los servicios de backend
Para detectar tráfico abusivo, como ataques de denegación de servicio (DOS), configure el monitoreo y las alertas para Cloud Firestore , Realtime Database , Cloud Storage y Hosting .
Si sospecha de un ataque a su aplicación, comuníquese con Soporte lo antes posible para informarles lo que está sucediendo.
Habilitar comprobación de aplicaciones
Para ayudar a garantizar que solo sus aplicaciones puedan acceder a sus servicios de back-end, habilite App Check para cada servicio que lo admita.
Configure sus Cloud Functions para escalar para el tráfico normal
Cloud Functions escala automáticamente para satisfacer las demandas de su aplicación, pero en caso de un ataque, esto puede significar una gran factura. Para evitar esto, puede limitar la cantidad de instancias simultáneas de una función en función del tráfico normal de su aplicación.
Configure alertas para recibir una notificación cuando casi se alcancen los límites
Si su servicio tiene picos de solicitudes, a menudo las cuotas se activarán y acelerarán automáticamente el tráfico a su aplicación. Asegúrese de monitorear su Panel de uso y facturación , pero también puede configurar alertas de presupuesto en su proyecto para recibir notificaciones cuando el uso de recursos supere las expectativas.
Evite las autodosis: pruebe las funciones localmente con los emuladores
Puede ser fácil usar DOS accidentalmente mientras desarrolla Cloud Functions: por ejemplo, al crear un bucle infinito de activación y escritura. Puede evitar que estos errores afecten a los servicios en vivo haciendo su desarrollo con el conjunto de emuladores de Firebase .
(Y si accidentalmente hace DOS usted mismo, anule la implementación de su función eliminándola de index.js y luego ejecute
Donde la capacidad de respuesta en tiempo real es menos importante, la estructura funciona a la defensiva
Si no necesita presentar el resultado de una función en tiempo real, puede mitigar el tráfico abusivo procesando los resultados en lotes: publique los resultados en un tema de Pub/Sub y procese los resultados a intervalos regulares con una función programada .
Comprender las claves API
Las claves de API para los servicios de Firebase no son secretas
Firebase usa claves de API solo para identificar el proyecto de Firebase de su aplicación en los servicios de Firebase, y no para controlar el acceso a la base de datos o a los datos de Cloud Storage, lo cual se hace mediante las reglas de seguridad de Firebase . Por este motivo, no es necesario tratar las claves de API para los servicios de Firebase como secretos y puede insertarlas de forma segura en el código del cliente. Obtén más información sobre las claves de API para Firebase .
Configurar el alcance de la clave API
Como disuasión adicional contra un atacante que intente usar su clave de API para falsificar solicitudes, puede crear claves de API en el ámbito de sus clientes de aplicaciones .
Mantener en secreto las claves del servidor de FCM
A diferencia de las claves de API para los servicios de Firebase, las claves de servidor de FCM (utilizadas por la API HTTP de FCM heredada ) son confidenciales y deben mantenerse en secreto.
Mantener en secreto las claves de la cuenta de servicio
Además, a diferencia de las claves de API para los servicios de Firebase, las claves privadas de la cuenta de servicio (utilizadas por el SDK de administrador ) son confidenciales y deben mantenerse en secreto.
Reglas de seguridad
Inicializar reglas en producción o modo bloqueado
Cuando configura Cloud Firestore, Realtime Database y Cloud Storage, inicialice sus reglas de seguridad para denegar todo acceso de manera predeterminada y agregue reglas que otorgan acceso a recursos específicos a medida que desarrolla su aplicación.
Esta es una de las configuraciones predeterminadas para nuevas instancias de Cloud Firestore (modo de producción) y Realtime Database (modo bloqueado). Elija esta opción cuando configure una nueva instancia de base de datos.
Para Cloud Storage, comience 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; agregue reglas cuando agregue documentos
No escriba reglas de seguridad después de escribir su aplicación, como una especie de tarea previa al lanzamiento. En su lugar, escribe reglas de seguridad a medida que escribes tu aplicación, tratándolas como un esquema de base de datos: cada vez que necesites usar un nuevo tipo de documento o estructura de ruta, primero escribe su regla de seguridad.
Reglas de seguridad de pruebas unitarias con Emulator Suite; agregarlo a CI
Para asegurarse de que sus reglas de seguridad se mantengan al día con el desarrollo de su aplicación, realice pruebas unitarias de sus reglas con el conjunto de emuladores de Firebase y agregue estas pruebas a su canalización de CI. Consulte estas guías para Cloud Firestore y Realtime Database .
Autenticación
Autenticación personalizada: Mint JWT de un entorno confiable (del lado del servidor)
Si ya tiene un sistema de inicio de sesión seguro, ya sea un sistema personalizado o un servicio de terceros, puede usar su sistema existente para autenticarse con los servicios de Firebase. Cree JWT personalizados desde un entorno confiable, luego pase los tokens a su cliente, que usa el token para autenticarse ( iOS+ , Android , Web , Unity , C++ ).
Para ver un ejemplo del uso de la autenticación personalizada con un proveedor externo, consulte la publicación de blog, Autenticar con Firebase usando Okta .
Autenticación gestionada: los proveedores de OAuth 2.0 son los más seguros
Si usa las funciones de autenticación administrada de Firebase, las opciones de proveedor de OAuth 2.0/OpenID Connect (Google, Facebook, etc.) son las más seguras. Debe admitir uno o más de estos proveedores si puede (dependiendo de su base de usuarios).
Autenticación de contraseña de correo electrónico: establezca una cuota estricta para el punto final de inicio de sesión para evitar ataques de fuerza bruta
Si usa el servicio de autenticación de contraseña de correo electrónico administrado de Firebase, reduzca la cuota predeterminada de los puntos finales de identitytoolkit.googleapis.com para evitar ataques de fuerza bruta. Puede hacerlo desde la página de la API en Google Cloud Console .
Autenticación de contraseña de correo electrónico: habilite la protección de enumeración de correo electrónico
Si usa el servicio de autenticación de contraseña de correo electrónico administrado de Firebase, habilite la protección de enumeración de correo electrónico , que evita que los actores malintencionados abusen de los extremos de autenticación de su proyecto para adivinar los nombres de las cuentas.
Actualice a Cloud Identity Platform para la autenticación multifactor
Para mayor seguridad en el inicio de sesión, puede agregar soporte de autenticación de múltiples factores actualizando a Cloud Identity Platform . Su código de autenticación de Firebase existente seguirá funcionando después de la actualización.
Autenticación anónima
Use solo la autenticación anónima para la incorporación en caliente
Utilice únicamente la autenticación anónima para guardar el estado básico de los usuarios antes de que realmente inicien sesión. La autenticación anónima no reemplaza el inicio de sesión del usuario.
Convierte a los usuarios a otro método de inicio de sesión si quieren los datos cuando pierden su teléfono
Los datos de autenticación anónimos no persistirán si el usuario borra el almacenamiento local o cambia de dispositivo. Si necesita conservar los datos más allá de los reinicios de la aplicación en un solo dispositivo, convierta al usuario en una cuenta permanente .
Use reglas de seguridad que requieran que los usuarios se hayan convertido a un proveedor de inicio de sesión o que hayan verificado su correo electrónico
Cualquiera puede crear una cuenta anónima en su proyecto. Con eso en mente, proteja todos los datos no públicos con reglas de seguridad que requieran métodos de inicio de sesión 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;
Gestión del medio ambiente
Configurar proyectos de desarrollo y puesta en escena
Configure proyectos de Firebase separados para desarrollo, preparación y producción. No combine el código del cliente con el de producción hasta que se haya probado con el proyecto de prueba.
Limite el acceso del equipo a los datos de producción
Si trabaja con un equipo más grande, puede mitigar las consecuencias de los errores y las infracciones al limitar el acceso a los datos de producción mediante roles predefinidos o roles de IAM personalizados.
Si su equipo usa el paquete de emuladores para el desarrollo, es posible que no necesite otorgar un acceso más amplio al proyecto de producción.
gestión de la biblioteca
Tenga cuidado con las faltas de ortografía de la biblioteca o los nuevos mantenedores
Al agregar bibliotecas a su proyecto, preste mucha atención al nombre de la biblioteca y sus mantenedores. Una biblioteca con un nombre similar a la que desea instalar podría contener código malicioso.
No actualice las bibliotecas sin comprender los cambios
Revise los registros de cambios de cualquier biblioteca que use antes de actualizar. Asegúrese de que la actualización agregue valor y verifique que el mantenedor siga siendo una parte en la que confía.
Instale bibliotecas de vigilancia como dependencias de desarrollo o prueba
Use una biblioteca como Snyk para escanear su proyecto en busca de dependencias inseguras.
Configurar el monitoreo de Funciones; compruébalo después de las actualizaciones de la biblioteca
Si usa el SDK del registrador de Cloud Functions , puede monitorear y recibir alertas sobre comportamientos inusuales, incluido el comportamiento causado por las actualizaciones de la biblioteca.
Seguridad de la función en la nube
Nunca coloque información confidencial en las variables de entorno de una función de nube.
A menudo, en una aplicación Node.js autohospedada, utiliza variables de entorno para contener información confidencial, como claves privadas. No hagas esto en Cloud Functions . Debido a que Cloud Functions reutiliza entornos entre invocaciones de funciones, la información confidencial no debe almacenarse en el entorno.
- Para almacenar las claves de la API de Firebase, que no son secretas , simplemente insértelas en el código.
- Si usa el SDK de administración de Firebase en una función de la nube, no es necesario que proporcione explícitamente las credenciales de la cuenta de servicio, ya que el SDK puede adquirirlas automáticamente durante la inicialización.
- Si está llamando a las API de Google y Google Cloud que requieren credenciales de cuenta de servicio, la biblioteca de Google Auth para Node.js puede obtener estas credenciales de las credenciales predeterminadas de la aplicación , que se completan automáticamente en Cloud Functions.
- Para que las claves privadas y las credenciales de los servicios que no son de Google estén disponibles para sus Cloud Functions, use Cloud Secret Manager .
Cifrar información confidencial
Si no puede evitar pasar información confidencial a su Cloud Function, debe idear su propia solución personalizada para cifrar la información.
Las funciones simples son más seguras; si necesita complejidad, considere Cloud Run
Trate de mantener sus funciones en la nube lo más simples y comprensibles posible. La complejidad de sus funciones a menudo puede generar errores difíciles de detectar o comportamientos inesperados.
Si necesita configuraciones complejas de lógica o entorno, considere usar Cloud Run en lugar de Cloud Functions.