Segredos de desenvolvimento de front-end
No desenvolvimento de front-end, medidas adequadas devem ser tomadas para garantir que segredos e credenciais sejam armazenados e gerenciados adequadamente, pois têm o potencial de causar confusão com práticas imprudentes. Neste artigo, veremos as melhores maneiras de gerenciar segredos e chaves geralmente de APIs.
APIs podem ser APIs privadas ou públicas. Uma API privada é uma API desenvolvida e hospedada por desenvolvedores internos de uma organização. APIs privadas estão disponíveis apenas para desenvolvedores internos e não são compartilhadas ou usadas por desenvolvedores fora dessa organização. APIs privadas são facilmente gerenciadas, pois os desenvolvedores têm controle total sobre como os aplicativos são desenvolvidos com elas. Uma API privada é basicamente uma API que permite a interface com um recurso de aplicativo criado por desenvolvedores em uma determinada organização. Um bom exemplo de API privada é a API desenvolvida por um desenvolvedor de back-end que permite a você (o desenvolvedor de front-end) acesso aos dados de sua organização. Como as APIs privadas são restritas, não há necessidade de incluir uma chave ou segredo antes de usar a API.
Por outro lado, uma API pública é um serviço de API oferecido por terceiros que está disponível publicamente e que fornece acesso a um aplicativo de software proprietário ou serviço da web. Como o nome indica, as APIs públicas estão disponíveis para todos os desenvolvedores, tanto dentro quanto fora da organização onde foram desenvolvidas. Eles permitem que os desenvolvedores aproveitem os recursos já disponíveis para aprimorar seus aplicativos, em vez de criar esses recursos do zero. Um bom exemplo de API pública é a API do Google Maps, que permite aos desenvolvedores usar o Google Maps em seus aplicativos. Alguns provedores de serviço oferecem suas APIs públicas gratuitamente por toda a vida, enquanto outros são pagos ou gratuitos para um número específico de solicitações. Para autorização e autenticação eficazes, os provedores de API usam chaves e segredos de credenciais exclusivos para cada usuário da API. Essas chaves e segredos devem ser gerenciados e armazenados com segurança, pois podem representar sérios desafios se caírem nas mãos erradas.
Problemas potenciais que podem ocorrer como resultado de segredos expostos
Chaves de API e segredos de credenciais que não são armazenados adequadamente podem causar danos financeiros, regulatórios ou de reputação.
- Nos casos em que um provedor de serviços terceirizado como o Google Cloud Platform (GCP) oferece acesso ao serviço por uma taxa limitada, se seu segredo for exposto, você poderá ter o acesso negado ao serviço porque o usuário não autorizado agiu assim muitos pedidos em seu nome, excedendo assim o seu limite. Além de apenas exceder o seu limite, as contas podem disparar
- Se o segredo de sua credencial vazar e seu aplicativo violar os termos de uso do provedor de API, o provedor de API pode retirar seu acesso ao serviço e isso pode prejudicar a reputação de sua organização.
- Por fim, você perde o controle de seu recurso, pois o hacker pode instruir o provedor diretamente e ignorar sua lógica de negócios
- O hacker pode obter acesso a dados confidenciais que podem causar uma violação dos dados de sua organização
Práticas inadequadas
Incorporando seus segredos de credenciais diretamente em seu código
Usarei o React no seguinte snippet de código, mas ele pode ser aplicado a JavaScript vanilla e a outras estruturas também:
import React from"react"; índice const=()=> { const Api_key="1234567" Retorna( <> Olá, segredos
)
}
índice padrão de exportação;
Esta é uma prática inadequada porque o segredo da sua credencial pode ser facilmente extraído do navegador com as ferramentas de desenvolvimento. Isso pode ser feito simplesmente:
- Inspecione a página da web ou CTRL + SHIFT + I
- Vá para a guia “Fontes”
- Clique em static/js
- Clique em main.chunk.js
Você encontrará o segredo da sua credencial, muito fácil para qualquer um extrair:
Enviando sua base de código para git/GitHub com seu segredo diretamente em seu código
importar emailjs de ‘emailjs-com’
function App () { const handleSubmit=(e)=> { e.preventDefault (); emailjs .sendForm (`gmail`,"876TY43sa23r56y789", e.target, process.env.REACT_APP_USER_ID) .então( (resultado)=> {
alert ("Mensagem enviada, entraremos em contato com você em breve", result.text); }, (erro)=> { alert ("Ocorreu um erro, tente novamente", error.text); } );
}; Retorna( <>
)
}
exportar aplicativo padrão;
Essa também é uma prática ruim porque qualquer pessoa pode acessar seu repositório online. Mesmo que seu repositório seja um repositório privado, alguns hackers usam rastreadores do GitHub para rastrear repositórios em busca de segredos de credenciais. Uma boa solução para isso é armazenar seus segredos de credencial em um arquivo.env que veremos na próxima seção.
Se a qualquer momento você se comprometeu e enviou suas credenciais de API para seu repositório git, você deve redefinir a chave o mais rápido possível, isso pode ser feito acessando o painel do provedor de serviços de API ou remover todos os vestígios dele usando git rebase para remover o commit específico que adicionou as chaves.
Não definir restrições em sua chave ou segredo de API
A maioria dos provedores de serviço de API permite que você restrinja o uso definindo um limite no número de solicitações a serem feitas por dia e um URL específico a partir do qual a API pode ser acessada. Na imagem abaixo, nenhum domínio foi salvo, portanto, as solicitações podem ser enviadas de qualquer URL com as credenciais da API.
Boas práticas
Definir restrições na chave API
Alguns provedores de serviço permitem que você defina restrições ao uso da chave API, de modo que a chave API só pode ser acessada a partir do URL que você especificou. Isso significa que mesmo se um hacker obtiver acesso à sua chave, ela será inútil, pois só pode ser usada com a URL especificada. Além disso, você pode definir um limite diário de uso de suas credenciais de API. Na imagem abaixo, as solicitações à API só podem ser feitas para o URL que eu especifiquei.
Esconda suas chaves em um arquivo de variável de ambiente (.env)
Com um arquivo.env, seu segredo não está diretamente no seu código. Isso é particularmente bom com o git. Você pode carregar seu código para git e adicionar o arquivo.env ao seu arquivo.gitignore. Dessa forma, seu arquivo.env não será confirmado no GitHub. Isso pode ser feito com as seguintes etapas:
- Crie um arquivo.env na raiz do seu projeto:
-your_react_project_folder -público -src -node_modules -.env <-seu arquivo.env -.gitignore -package-lock.json -package.json
- No arquivo.env, adicione REACT_APP_ como um prefixo para seu nome de chave de API e defina o valor (para aplicativos React) e VUE_APP_ como um prefixo para seu nome de chave de API e defina o valor (para aplicativos Vue). Isso permite que as estruturas identifiquem as variáveis:
#.env REACT_APP_YOUR_API_KEY_NAME=your_api_key <-para aplicativos de reação VUE_APP_YOUR_API_KEY_NAME=your_api_key <-para aplicativos vue # Exemplo: REACT_APP_TEMPLATE_ID=98765432123456789 REACT_APP_USER_ID=98765432123567 VUE_APP_USER_ID=98765432123456789
Adicione o arquivo.env ao seu arquivo.gitignore, desta forma seu arquivo.env não está comprometido com git e isso oculta sua chave de API quando você envia seu repo para GitHub:
arquivo #.gitignore # dependências /node_modules # env .env
Agora você pode usar a chave API em seu código anexando process.env:
//app.js
//aqui, usei as chaves api de emailjs já declaradas no arquivo.env.
importar emailjs de ‘emailjs-com’
function App () { const handleSubmit=(e)=> { e.preventDefault (); emailjs .sendForm (`gmail`, process.env.REACT_APP_TEMPLATE_ID, e.target, process.env.REACT_APP_USER_ID) .então( (resultado)=> {
alert ("Mensagem enviada, entraremos em contato em breve", result.text); }, (erro)=> { alert ("Ocorreu um erro, tente novamente", error.text); } );
}; Retorna( <>
)
}
exportar aplicativo padrão;
Esta é uma boa prática, mas não muito segura, pois sua chave de API ainda está visível no devtool do navegador. Suas credenciais de API ainda farão parte da compilação e serão visíveis para qualquer pessoa que inspecionar seus arquivos. Assim como fizemos antes:
- Inspecione a página da web ou CTRL + SHIFT + I
- Vá para a guia “Fontes”
- Clique em static/js
- Clique em main.chunk.js
Você encontrará as chaves de API definidas nos arquivos.env nas devtools.
Faça a varredura de repositórios git com soluções de varredura secretas, como GitGuardian
Ferramentas de varredura de segredos são ferramentas que fazem a varredura de git commits em repositórios remotos, seja no GitHub, GitLab ou Bitbucket, para verificar se há segredos que foram confirmados acidentalmente. Isso ajuda a evitar que informações confidenciais sejam expostas a repositórios remotos. Com essas soluções, os segredos comprometidos com o repo são detectados e capturados automaticamente.
Para configurar o GitGuardian para o seu projeto:
- Selecione um plano adequado e crie uma conta em GitGuardian
- Confirme seu e-mail e faça login em seu painel
- No seu painel, vá para Integrações ⇒ Monitoramento da fonte ⇒ Instalar (para seu repo baseado na web-GitHub, GitLab, Github Enterprise)
- Depois de instalá-lo, selecione o projeto em seus repositórios
- GitGuardian verifica o repo e envia um e-mail informando sobre um possível vazamento de segredo
Não compartilhe credenciais GitHub
Não compartilhe credenciais do GitHub com ninguém fora de sua equipe de desenvolvimento e certifique-se de revogar o acesso para desenvolvedores que não trabalham mais em sua equipe.
Conclusão
Proteger chaves e segredos de API é muito importante em seu aplicativo front-end, dependendo do nível de segurança que você deseja para sua credencial de API. Armazenar segredos em um arquivo.env é bom, mas por si só não é seguro. Sempre certifique-se de definir restrições para sua chave. Com isso, mesmo que seu segredo seja vazado, ele será inútil nas mãos de quem tiver acesso a ele. Uma camada extra de segurança é o uso de serviços de varredura secreta para varrer seus repositórios. Use as práticas destacadas neste artigo para garantir que dados confidenciais sejam protegidos durante o trabalho em projetos.
Obrigado pela leitura.
A postagem Práticas recomendadas para gerenciar e armazenar segredos no desenvolvimento de front-end apareceu primeiro no LogRocket Blog .
