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 el tráfico abusivo, tales como ataques de denegación de servicio (DoS), creado monitoreo y alerta de la nube Firestore , la base de datos en tiempo real , almacenamiento en la nube , y Hosting

Si sospecha que un ataque a su aplicación, llegar a la ayuda tan pronto como sea posible para hacerles saber lo que está sucediendo.

Habilitar verificación de aplicaciones

Para ayudar a garantizar que sólo las aplicaciones pueden acceder a los servicios de servidor, active la aplicación Comprobar para cada servicio que lo soporta.

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, se puede limitar el número de instancias simultáneas de una función basada en el tráfico normal para 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 controlar su uso y el salpicadero de facturación , pero también se puede configurar alertas de presupuesto en su proyecto para ser notificado cuando el uso de recursos está superando las expectativas.

Evitar auto-DOS: probar 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 estos errores afecten a servicios en tiempo real haciendo su desarrollo con la suite de emulador Firebase .

(Y si lo hace accidentalmente DOS mismo, anular la implementación de la función de su quitándolo de index.js continuación, se ejecutan firebase deploy --only functions ).

Donde la capacidad de respuesta en tiempo real es menos importante, la estructura funciona a la defensiva

Si no es necesario presentar el resultado de una función en tiempo real, se puede mitigar el tráfico abusivo mediante el procesamiento de los resultados en lotes: publicar los resultados a un Pub / Sub tema, y procesar 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

Llaves usos de la API de base de fuego sólo para identificar proyectos Firebase de su aplicación a los servicios de base de fuego, y no a controlar el acceso a base de datos o datos de almacenamiento en la nube, que se realiza mediante firebase reglas de seguridad . Por este motivo, no es necesario que trate las claves de API para los servicios de Firebase como secretos, y puede insertarlas de forma segura en el código del cliente. Más información sobre claves de la API para Firebase .

Configurar el alcance de la clave de API

Como un elemento disuasorio adicional contra un atacante de intentar usar su clave de API a las solicitudes falsos, puede crear claves de la API de ámbito de aplicación a sus clientes .

Mantener en secreto las claves del servidor FCM

Claves de la API a diferencia de los servicios de base de fuego, claves de servidor FCM (utilizados por el legado FCM HTTP API ) son sensibles y deben mantenerse en secreto.

Mantener en secreto las claves de la cuenta de servicio

También a diferencia de claves de la API para los servicios de base de fuego, servicio representan las claves privadas (utilizado por el SDK del administrador ) son sensibles y deben mantenerse en secreto.

Reglas de seguridad

Inicializar reglas en modo de producción o bloqueado

Cuando configuras Cloud Firestore, Realtime Database y Cloud Storage, inicializa tus reglas de seguridad para denegar todos los accesos 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 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; agregar reglas cuando agrega 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 asegurarse de que sus normas de seguridad se mantienen al día con el desarrollo de su aplicación, prueba de unidad de sus reglas con la suite de emulador Firebase y añadir estas pruebas a su canal de CI. Ver estas guías para la nube Firestore y base de datos en tiempo real .

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. Crear JWTs personalizados desde un entorno de confianza, a continuación, pasar las fichas a su cliente, que utiliza el token para autenticar ( iOS , Android , Web , Unidad , C ++ ).

Para un ejemplo del uso de autenticación personalizado con un proveedor de terceros, consulte la entrada de blog, autenticarse 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 utiliza el servicio de autenticación de correo electrónico, contraseña gestionado de Firebase, apriete la cuota predeterminada de los identitytoolkit.googleapis.com puntos finales para evitar ataques de fuerza bruta. Puede hacerlo desde la página de la API de Google Cloud Console .

Actualice a Cloud Identity Platform para la autenticación multifactor

Para mayor seguridad de inicio de sesión, puede agregar soporte de autenticación de múltiples factores mediante la actualización a la nube Identidad de la Plataforma . 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 se conservarán si el usuario borra el almacenamiento local o cambia de dispositivo. Si necesita mantener los datos más allá de aplicación se reinicia en un solo dispositivo, convertir al usuario a 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 esto en mente, proteger todos los datos no públicas con las normas de seguridad que requieren direcciones de correo electrónico verificadas inicio de sesión específica o métodos .

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 al limitar el acceso a los datos de producción, ya sea utilizando funciones predefinidas o roles IAM personalizado.

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

Utilizar una biblioteca como Snyk para escanear su proyecto para dependencias inseguros.

Configurar la supervisión de funciones; compruébalo después de las actualizaciones de la biblioteca

Si utiliza el SDK de la nube Funciones de registrador , se puede controlar y ser alertado de comportamiento inusual, incluyendo 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 hacer esto en funciones de la nube. 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 API base de fuego, que son no secreta , sólo les incrustar en el código.
  • Si usa el SDK de Firebase Admin 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 llama API de Google y Google nube que requieren credenciales de la cuenta de servicios, la biblioteca de Google para Node.js de autenticación puede obtener estas credenciales de las credenciales predeterminadas de aplicación , que se rellenan automáticamente en funciones de la nube.
  • Para hacer que las claves privadas y las credenciales para servicios que no son de Google a disposición de sus funciones en la nube, usar la nube Secreto Gestor .

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 lógicas o entorno complejo, considere el uso de la nube de ejecución en lugar de las funciones de la nube.