Para manter os recursos do Firebase e os dados dos usuários seguros, siga estas diretrizes. Nem todos os itens se aplicarão necessariamente aos seus requisitos, mas tenha-os em mente ao desenvolver seu aplicativo.
Evite trânsito abusivo
Configurar monitoramento e alertas para serviços de back-end
Para detectar tráfego abusivo, como ataques de negação de serviço (DOS), configure monitoramento e alertas para Cloud Firestore , Realtime Database , Cloud Storage e Hosting
Se você suspeitar de um ataque ao seu aplicativo, entre em contato com o suporte o mais rápido possível para informar o que está acontecendo.
Habilitar verificação de aplicativos
Para ajudar a garantir que apenas seus aplicativos possam acessar seus serviços de back-end, habilite o App Check para todos os serviços que o suportam.
Configure o Cloud Functions para escalonar o tráfego normal
O Cloud Functions é dimensionado automaticamente para atender às demandas do seu aplicativo, mas no caso de um ataque, isso pode significar uma conta alta. Para evitar isso, você pode limitar o número de instâncias simultâneas de uma função com base no tráfego normal do seu aplicativo.
Configure alertas para ser notificado quando os limites estiverem quase atingidos
Se o seu serviço tiver picos de solicitação, muitas vezes as cotas entrarão em ação e limitarão automaticamente o tráfego para o seu aplicativo. Certifique-se de monitorar seu painel de uso e faturamento , mas você também pode definir alertas de orçamento em seu projeto para ser notificado quando o uso de recursos exceder as expectativas.
Evite auto-DOSes: teste funções localmente com os emuladores
Pode ser fácil fazer DOS acidentalmente durante o desenvolvimento do Cloud Functions: por exemplo, criando um loop infinito de gravação de gatilho. Você pode evitar que esses erros afetem os serviços ativos fazendo seu desenvolvimento com o pacote de emuladores do Firebase .
(E se você mesmo fizer o DOS acidentalmente, remova a implantação de sua função removendo-a de index.js e executando
Onde a capacidade de resposta em tempo real é menos importante, a estrutura funciona defensivamente
Se você não precisar apresentar o resultado de uma função em tempo real, poderá mitigar o tráfego abusivo processando os resultados em lotes: publique os resultados em um tópico do Pub/Sub e processe os resultados em intervalos regulares com uma função programada .
Entenda as chaves de API
As chaves de API para serviços do Firebase não são secretas
O Firebase usa chaves de API apenas para identificar o projeto Firebase do seu aplicativo para os serviços do Firebase, e não para controlar o acesso ao banco de dados ou aos dados do Cloud Storage, o que é feito usando as regras de segurança do Firebase . Por esse motivo, você não precisa tratar as chaves de API dos serviços do Firebase como segredos e pode incorporá-las com segurança no código do cliente. Saiba mais sobre chaves de API para Firebase .
Configurar o escopo da chave de API
Como um impedimento adicional contra um invasor que tente usar sua chave de API para falsificar solicitações, você pode criar chaves de API com escopo para os clientes do seu aplicativo .
Mantenha as chaves do servidor FCM em segredo
Ao contrário das chaves de API para serviços do Firebase, as chaves do servidor FCM (usadas pela API HTTP FCM legada ) são confidenciais e devem ser mantidas em segredo.
Mantenha as chaves da conta de serviço secretas
Além disso, diferentemente das chaves de API dos serviços do Firebase, as chaves privadas da conta de serviço (usadas pelo Admin SDK ) são confidenciais e devem ser mantidas em segredo.
Regras de segurança
Inicialize regras em modo de produção ou bloqueado
Ao configurar o Cloud Firestore, o Realtime Database e o Cloud Storage, inicialize suas regras de segurança para negar todo o acesso por padrão e adicione regras que concedam acesso a recursos específicos à medida que você desenvolve seu aplicativo.
Esta é uma das configurações padrão para novas instâncias do Cloud Firestore (modo de produção) e Realtime Database (modo bloqueado). Escolha esta opção ao configurar uma nova instância de banco de dados.
Para o Cloud Storage, comece com uma configuração de regras de segurança como esta:
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if false;
}
}
}
As regras de segurança são um esquema; adicione regras ao adicionar documentos
Não escreva regras de segurança depois de escrever seu aplicativo, como uma espécie de tarefa de pré-lançamento. Em vez disso, escreva regras de segurança enquanto escreve seu aplicativo, tratando-as como um esquema de banco de dados: sempre que precisar usar um novo tipo de documento ou estrutura de caminho, escreva primeiro sua regra de segurança.
Regras de segurança de testes unitários com o Emulator Suite; adicione-o ao CI
Para garantir que suas regras de segurança estejam acompanhando o desenvolvimento do seu aplicativo, faça testes de unidade com o pacote de emuladores do Firebase e adicione esses testes ao pipeline de CI. Consulte estes guias para Cloud Firestore e Realtime Database .
Autenticação
Autenticação personalizada: crie JWTs de um ambiente confiável (lado do servidor)
Se você já possui um sistema de login seguro, seja um sistema personalizado ou um serviço de terceiros, poderá usar o sistema existente para autenticar com os serviços do Firebase. Crie JWTs personalizados a partir de um ambiente confiável e, em seguida, passe os tokens para seu cliente, que usa o token para autenticação ( iOS+ , Android , Web , Unity , C++ ).
Para ver um exemplo de uso de autenticação personalizada com um provedor terceirizado, consulte a postagem do blog Authenticate with Firebase using Okta .
Autenticação gerenciada: os provedores OAuth 2.0 são os mais seguros
Se você usa os recursos de autenticação gerenciada do Firebase, as opções do provedor OAuth 2.0/OpenID Connect (Google, Facebook, etc.) são as mais seguras. Você deve oferecer suporte a um ou mais desses provedores, se puder (dependendo da sua base de usuários).
Autenticação de senha de e-mail: defina uma cota restrita para o endpoint de login para evitar ataques de força bruta
Se você usa o serviço gerenciado de autenticação de e-mail e senha do Firebase, restrinja a cota padrão dos endpoints identitytoolkit.googleapis.com para evitar ataques de força bruta. Você pode fazer isso na página da API no console do Google Cloud .
Autenticação por senha de e-mail: Habilitar proteção de enumeração de e-mail
Se você usa o serviço gerenciado de autenticação de senha de e-mail do Firebase, ative a proteção de enumeração de e-mail , que evita que agentes mal-intencionados abusem dos endpoints de autenticação do seu projeto para adivinhar nomes de contas.
Faça upgrade para o Cloud Identity Platform para autenticação multifator
Para maior segurança no login, você pode adicionar suporte à autenticação multifator fazendo upgrade para o Cloud Identity Platform . Seu código existente do Firebase Authentication continuará funcionando após o upgrade.
Autenticação anônima
Use autenticação anônima apenas para integração calorosa
Use apenas a autenticação anônima para salvar o estado básico dos usuários antes que eles realmente entrem. A autenticação anônima não substitui a entrada do usuário.
Converta os usuários para outro método de login se eles quiserem os dados quando perderem o telefone
Os dados de autenticação anônima não persistirão se o usuário limpar o armazenamento local ou trocar de dispositivo. Se você precisar manter os dados além das reinicializações do aplicativo em um único dispositivo, converta o usuário para uma conta permanente .
Use regras de segurança que exijam que os usuários tenham se convertido em um provedor de login ou verificado seu e-mail
Qualquer pessoa pode criar uma conta anônima em seu projeto. Com isso em mente, proteja todos os dados não públicos com regras de segurança que exijam métodos de login específicos ou endereços de e-mail verificados .
Por exemplo:
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
Gestão ambiental
Configurar projetos de desenvolvimento e preparação
Configure projetos separados do Firebase para desenvolvimento, preparação e produção. Não mescle o código do cliente com a produção até que ele seja testado no projeto de preparo.
Limite o acesso da equipe aos dados de produção
Se você trabalha com uma equipe maior, poderá mitigar as consequências de erros e violações limitando o acesso aos dados de produção usando funções predefinidas ou funções IAM personalizadas.
Se sua equipe usar o pacote de emuladores para desenvolvimento, talvez você não precise conceder acesso mais amplo ao projeto de produção.
Gestão de biblioteca
Cuidado com erros ortográficos da biblioteca ou novos mantenedores
Ao adicionar bibliotecas ao seu projeto, preste muita atenção ao nome da biblioteca e de seus mantenedores. Uma biblioteca com nome semelhante àquela que você pretende instalar pode conter código malicioso.
Não atualize bibliotecas sem entender as mudanças
Examine os logs de alterações de todas as bibliotecas que você usa antes de atualizar. Certifique-se de que a atualização agrega valor e verifique se o mantenedor ainda é uma pessoa em quem você confia.
Instale bibliotecas watchdog como dependências de desenvolvimento ou teste
Use uma biblioteca como Snyk para verificar se há dependências inseguras em seu projeto.
Configurar monitoramento para Funções; verifique após as atualizações da biblioteca
Se você usar o SDK do agente de log do Cloud Functions , poderá monitorar e ser alertado sobre comportamentos incomuns, incluindo comportamentos causados por atualizações da biblioteca.
Segurança da função Cloud
Nunca coloque informações confidenciais nas variáveis de ambiente de uma função do Cloud
Muitas vezes, em um aplicativo Node.js auto-hospedado, você usa variáveis de ambiente para conter informações confidenciais, como chaves privadas. Não faça isso no Cloud Functions . Como o Cloud Functions reutiliza ambientes entre invocações de funções, informações confidenciais não devem ser armazenadas no ambiente.
- Para armazenar chaves de API do Firebase, que não são secretas , basta incorporá-las no código.
- Se você estiver usando o SDK Admin do Firebase em uma função do Cloud, não será necessário fornecer explicitamente as credenciais da conta de serviço, porque o SDK pode adquiri-las automaticamente durante a inicialização.
- Se você estiver chamando APIs do Google e do Google Cloud que exigem credenciais de conta de serviço, a biblioteca Google Auth para Node.js poderá obter essas credenciais das credenciais padrão do aplicativo , que são preenchidas automaticamente no Cloud Functions.
- Para disponibilizar chaves privadas e credenciais de serviços que não são do Google para seu Cloud Functions, use o Cloud Secret Manager .
Criptografe informações confidenciais
Se não for possível evitar a transmissão de informações confidenciais para sua função do Cloud, você deverá criar sua própria solução personalizada para criptografar as informações.
Funções simples são mais seguras; se você precisar de complexidade, considere o Cloud Run
Tente manter o Cloud Functions o mais simples e compreensível possível. A complexidade em suas funções muitas vezes pode levar a bugs difíceis de detectar ou a comportamentos inesperados.
Se você precisar de configurações complexas de lógica ou ambiente, considere usar o Cloud Run em vez do Cloud Functions.