Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Lista de verificación de seguridad de Firebase

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 desarrolle su aplicación.

Evite el tráfico abusivo

Configure el monitoreo 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 el 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 de backend, habilite App Check para cada servicio que lo admita.

Configura tus 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 notificaciones cuando se alcancen los límites

Si su servicio tiene picos de solicitudes, a menudo las cuotas se activarán y automáticamente limitarán 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.

Evitar auto-DOS: probar funciones localmente con los emuladores

Puede ser fácil ejecutar accidentalmente DOS usted mismo mientras desarrolla Cloud Functions: por ejemplo, creando un bucle infinito de activación y escritura. Puede evitar que estos errores afecten a los servicios en vivo realizando su desarrollo con el conjunto de emuladores de Firebase .

(Y si accidentalmente usa DOS usted mismo, firebase deploy --only functions su función eliminándola de index.js luego ejecutando firebase deploy --only functions ).

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 de 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 tu aplicación en los servicios de Firebase, y no para controlar el acceso a la base de datos o los datos de Cloud Storage, lo cual se realiza mediante las reglas de seguridad de Firebase . Por este motivo, no es necesario que trate las claves de API para los servicios de Firebase como secretos, y puede incrustarlas 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 de API

Como elemento disuasorio adicional contra un atacante que intente utilizar su clave de API para falsificar solicitudes, puede crear claves de API con alcance para sus clientes de aplicaciones .

Mantener en secreto las claves del servidor 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 modo de producción o bloqueado

Cuando configura Cloud Firestore, Realtime Database y Cloud Storage, inicializa sus reglas de seguridad para denegar todo acceso de forma predeterminada y agrega 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, escriba reglas de seguridad a medida que escribe su aplicación, tratándolas como un esquema de base de datos: siempre que necesite usar un nuevo tipo de documento o estructura de ruta, primero escriba su regla de seguridad.

Reglas de seguridad de prueba unitaria con Emulator Suite; agregarlo a CI

Para asegurarte de que tus reglas de seguridad se mantengan al día con el desarrollo de tu aplicación, prueba unitariamente tus reglas con el conjunto de emuladores de Firebase y agrega estas pruebas a tu canalización de CI. Consulta estas guías para Cloud Firestore y Realtime Database .

Autenticación

Autenticación personalizada: mint JWT desde un entorno de confianza (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 del blog, Autenticar con Firebase usando Okta .

Autenticación administrada: los proveedores de OAuth 2.0 son los más seguros

Si usa 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 apoyar a uno o más de estos proveedores si puede (dependiendo de su base de usuarios).

Autenticación de correo electrónico con contraseña: establezca una cuota ajustada 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, ajuste la cuota predeterminada de los puntos finales identitytoolkit.googleapis.com para evitar ataques de fuerza bruta. Puede hacerlo desdela página dela API en Google Cloud Console .

Actualice a Cloud Identity Platform para la autenticación multifactor

Para mayor seguridad en el inicio de sesión, puede agregar compatibilidad con la autenticación multifactor mediante la actualización 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 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.

Convierta 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á del reinicio de la aplicación en un solo dispositivo, convierta al usuario en una cuenta permanente .

Utilice reglas de seguridad que requieran que los usuarios se hayan convertido en 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 requieren 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 medioambiental

Configurar proyectos de desarrollo y puesta en escena

Configure proyectos de Firebase separados para el desarrollo, la puesta en escena y la producción. No combine el código del cliente con la producción hasta que se haya probado con el proyecto de ensayo.

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 limitando 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 bibliotecas

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 encargados. 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 las bibliotecas que utilice 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

Utilice una biblioteca como Snyk para escanear su proyecto en busca de dependencias inseguras.

Configurar la supervisión 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 de nube

Nunca coloque información confidencial en las variables de entorno de una función en la 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 incrústalas en el código.
  • Si usa el SDK de Firebase Admin en una función de 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 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 hacer que las claves privadas y las credenciales de servicios que no sean de Google estén disponibles para sus Funciones de Cloud, use Cloud Secret Manager .

Cifre la 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 que sus funciones en la nube sean 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 configuraciones de entorno o lógica compleja, considere usar Cloud Run en lugar de Cloud Functions.