Para mantener seguros tus recursos de Firebase y los datos de tus usuarios, sigue estas pautas. No todos los elementos se aplicarán necesariamente a sus requisitos, pero téngalos en cuenta a medida que desarrolle su aplicación.
Evite el tráfico abusivo
Configurar monitoreo y alertas para servicios 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 verificación de aplicaciones
Para ayudar a garantizar que solo sus aplicaciones puedan acceder a sus servicios backend, habilite App Check para cada servicio que lo admita.
Configure sus funciones en la nube para escalar para el tráfico normal
Cloud Functions se 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 según el tráfico normal de su aplicación.
Configure alertas para recibir notificaciones cuando los límites estén casi alcanzados
Si su servicio tiene picos de solicitudes, a menudo se activarán cuotas y limitará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 los autoDOS: pruebe las funciones localmente con los emuladores
Puede ser fácil hacer DOS accidentalmente mientras desarrolla Cloud Functions: por ejemplo, creando un bucle infinito de activación y escritura. Puede evitar que estos errores afecten los servicios en vivo realizando su desarrollo con el conjunto de emuladores Firebase .
(Y si usted mismo hace DOS accidentalmente, 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 de manera 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 API para los servicios de Firebase no son secretas
Firebase usa claves API solo para identificar el proyecto 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 realiza mediante las reglas de seguridad de Firebase . Por este motivo, no es necesario que trates las claves de API para los servicios de Firebase como secretas y puedes incrustarlas de forma segura en el código del cliente. Obtenga más información sobre las claves API para Firebase .
Configurar el alcance de la clave API
Como elemento disuasivo adicional contra un atacante que intente utilizar su clave API para falsificar solicitudes, puede crear claves API específicas para los clientes de su aplicación .
Mantenga las claves del servidor FCM en secreto
A diferencia de las claves API para los servicios de Firebase, las claves del servidor FCM (utilizadas por la API HTTP de FCM heredada ) son confidenciales y deben mantenerse en secreto.
Mantenga en secreto las claves de la cuenta de servicio
Además, a diferencia de las claves 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 configuras Cloud Firestore, Realtime Database y Cloud Storage, inicializa tus reglas de seguridad para denegar todo acceso de forma predeterminada y agrega reglas que otorguen acceso a recursos específicos a medida que desarrollas tu 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 al configurar 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; agregar reglas al agregar documentos
No escriba reglas de seguridad después de escribir su aplicación, como una especie de tarea previa al lanzamiento. En su lugar, escriba reglas de seguridad a medida que escribe su aplicación, tratándolas como un esquema de base de datos: siempre que necesite utilizar un nuevo tipo de documento o estructura de ruta, escriba primero su regla de seguridad.
Reglas de seguridad de prueba unitaria 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, pruebe sus reglas con el conjunto de emuladores Firebase y agregue estas pruebas a su canal de CI. Consulte estas guías para Cloud Firestore y Realtime Database .
Autenticación
Autenticación personalizada: creación de JWT desde 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 y 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 del blog Autenticar con Firebase usando Okta .
Autenticación gestionada: los proveedores de OAuth 2.0 son los más seguros
Si utiliza las funciones de autenticación administrada de Firebase, las opciones del proveedor 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 con 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 utiliza el servicio de autenticación de contraseña de correo electrónico administrado de Firebase, ajuste la cuota predeterminada de los puntos finales 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 de contraseña de correo electrónico: habilite la protección de enumeración de correo electrónico
Si utiliza 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 actores malintencionados abusen de los puntos finales de autenticación de su proyecto para adivinar los nombres de las cuentas.
Actualice a Cloud Identity Platform para obtener autenticación multifactor
Para mayor seguridad al iniciar sesión, puede agregar compatibilidad con autenticación multifactor 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
Utilice únicamente autenticación anónima para una incorporación cálida
Utilice únicamente la autenticación anónima para guardar el estado básico de los usuarios antes de que inicien sesión. La autenticación anónima no reemplaza el inicio de sesión del usuario.
Convierta a los usuarios a otro método de inicio de sesión si quieren los datos cuando pierdan 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 datos más allá del reinicio de la aplicación en un solo dispositivo, convierta el usuario en una cuenta permanente .
Utilice reglas de seguridad que requieran que los usuarios se hayan convertido a un proveedor de inicio de sesión o hayan verificado su correo electrónico.
Cualquiera puede crear una cuenta anónima en su proyecto. Teniendo esto en cuenta, 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 ambiental
Establecer proyectos de desarrollo y puesta en escena.
Configure proyectos de Firebase separados para desarrollo, puesta en escena y producción. No combine el código del cliente con producción hasta que se haya probado con el proyecto de prueba.
Limitar el acceso del equipo a los datos de producción
Si trabaja con un equipo más grande, puede mitigar las consecuencias de errores e infracciones limitando el acceso a los datos de producción mediante roles predefinidos o roles de IAM personalizados.
Si su equipo utiliza el conjunto de emuladores para el desarrollo, es posible que no necesite otorgar un acceso más amplio al proyecto de producción.
Gestión de biblioteca
Tenga cuidado con los errores ortográficos 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 al 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 utilice antes de actualizar. Asegúrese de que la actualización agregue valor y verifique que el mantenedor siga siendo una parte de su confianza.
Instale bibliotecas de vigilancia como dependencias de desarrollo o prueba
Utilice 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 utiliza el SDK del registrador de Cloud Functions , puede monitorear y recibir alertas sobre comportamientos inusuales, incluido el comportamiento causado por actualizaciones de la biblioteca.
Seguridad de la función en la nube
Nunca coloques información confidencial en las variables de entorno de una función en la nube
A menudo, en una aplicación Node.js autohospedada, se utilizan 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 claves API de Firebase, que no son secretas , simplemente incorpórelas en el código.
- Si usa el SDK de administrador de Firebase en una función de nube, no necesita proporcionar explícitamente las credenciales de la cuenta de servicio, ya que el SDK puede adquirirlas automáticamente durante la inicialización.
- Si llama a las API de Google y Google Cloud que requieren credenciales de cuenta de servicio, la biblioteca de autenticación de Google 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 servicios que no son de Google estén disponibles para sus Cloud Functions, utilice Cloud Secret Manager .
Cifrar información confidencial
Si no puede evitar pasar información confidencial a su función en la nube, debe crear su propia solución personalizada para cifrar la información.
Las funciones simples son más seguras; si necesita complejidad, considere Cloud Run
Intente mantener sus funciones en la nube lo más simples y comprensibles posible. La complejidad de sus funciones a menudo puede provocar errores difíciles de detectar o comportamientos inesperados.
Si necesita lógica compleja o configuraciones de entorno, considere usar Cloud Run en lugar de Cloud Functions.