Para manter os recursos do Firebase e os dados dos seus usuários seguros, siga estas diretrizes. Nem todos os itens são aplicáveis necessariamente aos seus requisitos, mas lembre-se deles ao desenvolver seu app.
Evitar tráfego abusivo
Configurar o monitoramento e os alertas de serviços de back-end
Para detectar tráfego abusivo, como ataques de negação de serviço (DOS), configure o monitoramento e os alertas paraCloud Firestore, Realtime Database, Cloud Storage e Hosting
Se você suspeitar de um ataque no seu aplicativo, entre em contato com o suporte o mais rápido possível para informar sobre o que está acontecendo.
Ativar o App Check
Para ajudar a garantir que apenas seus apps possam acessar os serviços de back-end, ative o App Check para cada serviço com suporte a ele.
Configurar o Cloud Functions para escalonar para o tráfego normal
O Cloud Functions é escalonado automaticamente para atender às demandas do seu app. No entanto, em caso de ataque, isso pode gerar uma grande fatura. Para evitar isso, é possível limitar o número de instâncias simultâneas de uma função com base no tráfego normal do app.
Configurar alertas para ser notificado quando os limites estiverem perto de serem alcançados
Se o serviço tiver picos de solicitação, muitas vezes as cotas serão iniciadas e limitarão automaticamente o tráfego para o aplicativo. Monitore o painel de uso e faturamento, mas também é possível definir alertas de orçamento no projeto para ser notificado quando o uso de recursos exceder as expectativas.
Evitar 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 e gatilho. É possível evitar que esses erros afetem os serviços ativos fazendo seu desenvolvimento com o conjunto de emuladores do Firebase.
Se você mesmo fizer DOS, desabilite a função removendo
index.js e, em seguida, execute
Quando a capacidade de resposta em tempo real é menos importante, estruture as funções de maneira defensiva
Se você não precisa apresentar o resultado de uma função em tempo real, é possível reduzir o tráfego abusivo processando os resultados em lotes: publique os resultados em um tópico Pub/Sub e processe os resultados em intervalos regulares com uma função programada.
Entender as chaves de API
As chaves de API para serviços do Firebase não são secretas
O Firebase usa chaves de API somente para identificar o projeto do Firebase do seu app nos serviços do Firebase e não para controlar o acesso aos dados do banco de dados ou 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 para os serviços do Firebase como secrets, e é possível incorporá-las com segurança ao código do cliente. Saiba mais sobre as chaves de API do Firebase.
Configurar o escopo da chave de API
Como um bloqueio adicional contra um invasor tentando usar sua chave de API para falsificar solicitações, é possível criar chaves de API com escopo para os clientes do app.
Manter as chaves de servidor do FCM em segredo
Ao contrário das chaves de API para serviços do Firebase, as chaves de servidor do FCM (usadas pela API FCM HTTP legada) são confidenciais e precisam ser mantidas em segredo.
Manter as chaves da conta de serviço em segredo
Além disso, diferentemente das chaves de API para serviços do Firebase, as chaves privadas da conta de serviço, usadas pelo SDK Admin, são confidenciais e precisam ser mantidas em segredo.
Regras de segurança
Inicializar regras em modo de produção ou bloqueado
Ao configurar o Cloud Firestore, o Realtime Database e o Cloud Storage, inicialize as regras de segurança para negar todo o acesso por padrão e adicione regras que concedem acesso a recursos específicos durante o desenvolvimento do app.
Esta é uma das configurações padrão para novas instâncias do Cloud Firestore (modo de produção) e do Realtime Database (modo bloqueado). Escolha essa 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 a seguinte:
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: adicionar regras ao adicionar documentos
Não escreva regras de segurança depois de criar o app como um tipo de tarefa de pré-lançamento. Em vez disso, escreva as regras de segurança enquanto cria seu app, tratando-as como um esquema de banco de dados: sempre que você precisar usar um novo tipo de documento ou estrutura de caminho, escreva a regra de segurança correspondente primeiro.
Regras de segurança de teste de unidade com o conjunto de emuladores. Adicione-as à CI
Para garantir que as regras de segurança estejam acompanhando o desenvolvimento do app, faça o teste de unidade das regras com o pacote do emulador do Firebase e adicione esses testes ao pipeline de CI. Consulte estes guias sobre o Cloud Firestore e o Realtime Database.
Autenticação
Autenticação personalizada: crie JWTs a partir de um ambiente confiável (do lado do servidor)
Se você já tem um sistema de login seguro, seja um sistema personalizado ou um serviço de terceiros, use seu sistema atual para autenticar com os serviços do Firebase. Criar JWTs personalizados em um ambiente confiável e transferir os tokens para o cliente, que o usará para fazer a autenticação (iOS+, Android, Web, Unity e C++).
Para um exemplo de como usar a autenticação personalizada com um provedor de terceiros, consulte a postagem do blog Autenticar com o Firebase usando o Okta (em inglês).
Autenticação gerenciada: os provedores OAuth 2.0 são os mais seguros
Se você usa os recursos de autenticação gerenciados do Firebase, as opções de provedor OAuth 2.0/OpenID Connect (Google, Facebook etc.) são as mais seguras. Dê suporte a um ou mais provedores se possível, dependendo da base de usuários.
Autenticação de e-mails/senha: defina uma cota restrita para o ponto de extremidade de login para evitar ataques de força bruta
Se você usa o serviço gerenciado de autenticação de senha de e-mail do Firebase, restrinja a
cota padrão dos endpoints identitytoolkit.googleapis.com para evitar ataques de
força bruta. Faça isso na página da API no Console do Google Cloud.
Autenticação de senha de e-mail: ative a proteção contra enumeração de e-mails
Se você usa o serviço gerenciado de autenticação de senha de e-mail do Firebase, ative a proteção contra enumeração de e-mails, o que impede que agentes mal-intencionados acessem os endpoints de autenticação do seu projeto para adivinhar nomes de contas.
Fazer upgrade para o Cloud Identity Platform para autenticação multifator
Para aumentar a segurança do login, adicione suporte à autenticação multifator ao fazer upgrade para o Cloud Identity Platform. Seu código do Firebase Authentication atual continuará funcionando depois do upgrade.
Autenticação anônima
Usar apenas autenticação anônima para integração lenta
Use a autenticação anônima para salvar o estado básico para os usuários antes que eles façam login. A autenticação anônima não substitui o login do usuário.
Converter usuários com outro método de login se eles quiserem os dados quando perderem o telefone
Os dados de autenticação anônimos não serão mantidos se o usuário limpar o armazenamento local ou mudar de dispositivo. Se você precisar manter os dados além das reinicializações do app em um único dispositivo, converta o usuário em uma conta permanente.
Usar regras de segurança que exigem que os usuários sejam convertidos em um provedor de login ou que tenham verificado o e-mail
Qualquer pessoa pode criar uma conta anônima no seu projeto. Pensando nisso, proteja todos os dados não públicos com regras de segurança que exigem métodos de login específicos ou endereços de e-mail verificados.
Exemplo:
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
Gerenciamento de ambiente
Configurar projetos de desenvolvimento e preparo
Configurar projetos do Firebase separados para desenvolvimento, preparo e produção. Não mescle o código do cliente na produção até que ele seja testado em relação ao projeto de preparo.
Limitar o acesso da equipe aos dados de produção
Se você trabalha com uma equipe maior, é possível reduzir as consequências de erros e violações. Para isso, limite o acesso aos dados de produção usando papéis predefinidos ou papéis personalizados do IAM.
Se sua equipe usa o pacote do emulador para desenvolvimento, talvez você não precise conceder acesso mais amplo ao projeto de produção.
Gerenciamento de bibliotecas
Cuidado com erros de digitação ou novos mantenedores
Ao adicionar bibliotecas ao seu projeto, preste muita atenção ao nome da biblioteca e seus mantenedores. Uma biblioteca com nome semelhante à que você pretende instalar pode conter código malicioso.
Não atualizar bibliotecas sem entender as alterações
Verifique os registros de alterações das bibliotecas que você usa antes do upgrade. O upgrade precisa agregar valor e verificar se o mantenedor ainda é uma parte confiável.
Instalar bibliotecas de watchdog como dependências de desenvolvimento ou de teste
Use uma biblioteca, como Snyk, para verificar o projeto em busca de dependências não seguras.
Configure o monitoramento do Functions. Verifique depois da atualização da biblioteca
Se você usa o SDK do logger do Cloud Functions, é possível monitorar e receber alertas de comportamento incomum, incluindo o comportamento causado por atualizações da biblioteca.
Segurança do Cloud Functions
Nunca coloque informações confidenciais nas variáveis de ambiente do Cloud Functions
Em um app Node.js auto-hospedado, as variáveis de ambiente são usadas 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ção, as informações confidenciais não podem ser armazenadas no ambiente.
- Para armazenar chaves de API do Firebase, que não são secretas, basta incorporá-las ao 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 as APIs do Google e do Google Cloud que exigem credenciais de conta de serviço, a biblioteca do Google Auth para Node.js pode receber essas credenciais das credenciais padrão do aplicativo que são preenchidas automaticamente no Cloud Functions.
- Para disponibilizar chaves e credenciais privadas de serviços que não sejam do Google para o Cloud Functions, use o Cloud Secret Manager.
Criptografar informações confidenciais
Se não for possível evitar a transmissão de informações confidenciais para a função do Cloud, crie sua própria solução personalizada para criptografar as informações.
Funções simples são mais seguras. Se precisar de complexidade, considere o Cloud Run
Tente manter o Cloud Functions o mais simples possível e fácil de entender. A complexidade das funções pode causar bugs difíceis de detectar ou comportamento inesperado.
Se você precisar de configurações complexas de lógica ou de ambiente, use o Cloud Run em vez do Cloud Functions.