É seguro expor o Firebase apiKey ao público?

O guia Firebase Web-App afirma que devo colocar o dado apiKeyno meu HTML para inicializar o Firebase:

// TODO: Replace with your project's customized code snippet
<script src="https://www.gstatic.com/firebasejs/3.0.2/firebase.js"></script>
<script>
  // Initialize Firebase
  var config = {
    apiKey: '<your-api-key>',
    authDomain: '<your-auth-domain>',
    databaseURL: '<your-database-url>',
    storageBucket: '<your-storage-bucket>'
  };
  firebase.initializeApp(config);
</script>

Ao fazer isso, o apiKeyé exposto a todos os visitantes. Qual é o objetivo dessa chave e ela realmente deve ser pública?

A apiKey neste snippet de configuração apenas identifica seu projeto Firebase nos servidores do Google. Não é um risco de segurança para alguém conhecê-lo. De fato, é necessário que eles saibam, para interagir com o seu projeto Firebase. Esses mesmos dados de configuração também estão incluídos em todos os aplicativos iOS e Android que usam o Firebase como back-end.

Nesse sentido, é muito parecido com o URL do banco de dados que identifica o banco de dados back-end associado ao seu projeto no mesmo trecho: https://<app-id>.firebaseio.com. Veja esta pergunta sobre por que isso não representa um risco à segurança: Como restringir a modificação de dados do Firebase? , incluindo o uso das regras de segurança do servidor do Firebase para garantir que apenas usuários autorizados possam acessar os serviços de back-end.

Se você quiser aprender como proteger todos os acessos de dados aos serviços de back-end do Firebase está autorizado, leia a documentação sobre as regras de segurança do Firebase .

Se você deseja reduzir o risco de confirmar esses dados de configuração no controle de versão, considere usar a configuração automática do SDK do Firebase Hosting . Embora as chaves ainda acabem no navegador no mesmo formato, elas não serão mais codificadas no seu código com isso.

Com base nas respostas de prufrofro e Frank van Puffelen aqui , montei essa configuração que não impede a raspagem, mas pode tornar um pouco mais difícil o uso da chave da API.

Aviso: para obter seus dados, mesmo com esse método, é possível, por exemplo, simplesmente abrir o console JS no Chrome e digitar:

firebase.database().ref("/get/all/the/data").once("value", function (data) {
    console.log(data.val());
});

Somente as regras de segurança do banco de dados podem proteger seus dados.

No entanto, restrinjai o uso da chave da API de produção ao meu nome de domínio da seguinte maneira:

1. https://console.developers.google.com/apis
2. Selecione seu projeto Firebase
3. Credenciais
4. Em chaves da API, escolha sua chave do navegador. Deve ter a seguinte aparência: " Chave do navegador (criada automaticamente pelo Serviço Google) "
5. Em " Aceitar solicitações dessas referências HTTP (web sites) ", adicionar o URL do seu aplicativo (exemple: projectname.firebaseapp.com/*)

Agora, o aplicativo funcionará apenas nesse nome de domínio específico. Então, criei outra chave de API que será privada para o desenvolvimento do host local.

1. Clique em Criar credenciais> Chave da API

Por padrão, como mencionado por Emmanuel Campos, o Firebase apenas lista de permissões localhoste o domínio de hospedagem do Firebase .

Para garantir que não publique a chave de API errada por engano, use um dos métodos a seguir para usar automaticamente a mais restrita na produção.

Configuração para Create-React-App

Em /env.development:

REACT_APP_API_KEY=###dev-key###

Em /env.production:

REACT_APP_API_KEY=###public-key###

No /src/index.js

const firebaseConfig = {
  apiKey: process.env.REACT_APP_API_KEY,
  // ... 
};

Minha configuração anterior para o Webpack:

Eu uso o Webpack para criar meu aplicativo de produção e coloco minha chave de API de desenvolvimento dentro da minha, index.htmlexatamente como você faria normalmente. Em seguida, dentro do meu webpack.production.config.jsarquivo, substituo a chave toda vez que index.htmlé copiada para a compilação de produção:

plugins: [
    new CopyWebpackPlugin([
      {
        transform: function(content, path) {
          return content.toString().replace("###dev-key###", "###public-key###");
        },
        from: './index.html'
      }
    ])
  ]

Não estou convencido de expor chaves de segurança / configuração ao cliente. Eu não chamaria isso de seguro, não porque alguém possa roubar todas as informações privadas desde o primeiro dia, porque alguém pode fazer solicitações excessivas, drenar sua cota e fazer com que você deva muito dinheiro ao Google.

Você precisa pensar em muitos conceitos, desde restringir as pessoas a não acessar onde elas não deveriam estar, ataques do DOS etc.

Eu preferiria que o cliente atingisse primeiro o seu servidor da Web, lá você coloca o que sempre é o firewall, captcha, cloudflare, segurança personalizada entre o cliente e o servidor ou entre o servidor e a base de firmas, e você está pronto para começar. Pelo menos você pode primeiro interromper a atividade suspeita antes que ela atinja a base do firebase. Você terá muito mais flexibilidade.

Eu vejo apenas um bom cenário de uso para usar a configuração baseada em cliente para usos internos. Por exemplo, você possui um domínio interno e tem certeza de que pessoas de fora não podem acessá-lo, portanto, pode configurar um ambiente como navegador -> tipo firebase.

Acredito que, uma vez que as regras do banco de dados sejam escritas com precisão, será suficiente para proteger seus dados. Além disso, existem diretrizes que se pode seguir para estruturar seu banco de dados de acordo. Por exemplo, criando um nó UID sob usuários e colocando todas as informações sob ele. Depois disso, você precisará implementar uma regra de banco de dados simples, como abaixo

  "rules": {
    "users": {
      "$uid": {
        ".read": "auth != null && auth.uid == $uid",
        ".write": "auth != null && auth.uid == $uid"
      }
    }
  }
}

Nenhum outro usuário poderá ler os dados de outros usuários; além disso, a política de domínio restringirá as solicitações provenientes de outros domínios. Pode-se ler mais sobre isso nas regras de segurança do Firebase

A exposição da chave da API cria uma vulnerabilidade quando a inscrição de usuário / senha está ativada. Há um ponto de extremidade da API aberto que pega a chave da API e permite que qualquer pessoa crie uma nova conta de usuário. Eles podem usar essa nova conta para fazer login no aplicativo protegido por autenticação do Firebase ou usar o SDK para autenticar com o usuário / passar e executar consultas.

Eu relatei isso ao Google, mas eles dizem que está funcionando conforme o esperado.

Se você não puder desativar as contas de usuário / senha, faça o seguinte: Crie uma função de nuvem para desativar automaticamente novos usuários noCriar e crie uma nova entrada de banco de dados para gerenciar seu acesso.

Por exemplo: Meus usuários / {userId} / Acesso: 0

exports.addUser = functions.auth.user().onCreate(onAddUser);
exports.deleteUser = functions.auth.user().onDelete(onDeleteUser);

Atualize suas regras para permitir apenas leituras para usuários com acesso> 1.

Na hipótese de a função de ouvinte não desabilitar a conta com rapidez suficiente, as regras de leitura os impedirão de ler quaisquer dados.

Depois de ler isso e depois de fazer algumas pesquisas sobre as possibilidades, criei uma abordagem um pouco diferente para restringir o uso de dados por usuários não autorizados:

Também salvo meus usuários no meu banco de dados (e também os dados do perfil). Então, eu apenas defino as regras de db assim:

".read": "auth != null && root.child('/userdata/'+auth.uid+'/userRole').exists()",
".write": "auth != null && root.child('/userdata/'+auth.uid+'/userRole').exists()"

Dessa maneira, apenas um usuário salvo anterior pode adicionar novos usuários ao banco de dados, de forma que ninguém sem uma conta possa executar operações no banco de dados. adicionar novos usuários também é possível apenas se o usuário tiver uma função especial e editar apenas pelo administrador ou pelo próprio usuário (algo como isto):

"userdata": {
  "$userId": {
    ".write": "$userId === auth.uid || root.child('/userdata/'+auth.uid+'/userRole').val() === 'superadmin'",
   ...

Você não deve expor essas informações. em público, especialmente chaves da API. Isso pode levar a um vazamento de privacidade.

Antes de tornar o site público, você deve ocultá-lo. Você pode fazer isso de 2 ou mais maneiras

1. Codificação / ocultação complexa
2. Basta colocar os códigos SDK do firebase na parte inferior do seu site ou aplicativo para que o firebase faça todos os trabalhos automaticamente. você não precisa colocar as chaves da API em qualquer lugar