Resumindo
- Todo arquivo que você publica pode ser lido por qualquer pessoa que consiga abrir o site, e um código de acesso não muda o que deve ficar ali. Mantenha chaves, senhas e dados de clientes fora dele.
- Sem servidor não quer dizer sem risco. Fique atento a chaves coladas, scripts externos e texto inserido com innerHTML.
- Se uma chave vazar, revogue primeiro. Apagar o arquivo não basta.
O que vai a público
Esta é a regra que vale lembrar. Quando você publica um site, todo arquivo dele pode ser baixado por quem souber o endereço. Isso inclui arquivos para os quais nenhuma página aponta. Esconder o código com “minificação” ou “ofuscação” só o torna mais difícil de ler, não secreto.
| Tipo de arquivo | Público? | Exemplo |
|---|---|---|
| HTML, CSS, JavaScript | Sim | Uma chave de API digitada em script.js |
| Imagens, PDFs, downloads | Sim | Um PDF de lista de preços para o qual nenhuma página aponta |
| Arquivos de configuração | Sim | config.json com um token dentro |
Arquivos .env | Sim, se enviado | Chaves guardadas ao lado do seu projeto |
Source maps (.map) | Sim, se enviado | Cópias legíveis do seu código original |
A pasta .git | Sim, se enviado | Histórico antigo com chaves “apagadas” dentro |
| Arquivos que você não publicou | Não | Anotações, rascunhos, o resto do seu projeto |
Onde as chaves secretas se escondem
As ferramentas de IA são boas em fazer as coisas funcionarem. Às vezes o jeito mais rápido é colar uma chave direto no código. Procure por isto:
- Chaves no JavaScript. Um widget de chatbot que chama um serviço de IA direto da página, com a chave no código. Qualquer pessoa pode copiar essa chave e aumentar sua conta.
- Arquivos
.env. Projetos guardam chaves em um arquivo chamado.env. Ele deveria ficar no seu computador, mas é enviado se você publica a pasta inteira do projeto. - Arquivos de configuração e de build. Arquivos de configurações, source maps e arquivos de teste esquecidos podem conter chaves ou caminhos que você não queria compartilhar.
- A pasta
.git. Essa pasta oculta guarda todo o histórico do seu projeto, incluindo chaves que foram “apagadas” há muito tempo.
Chaves públicas não têm problema
Algumas chaves foram feitas para ficar em uma página web: uma chave publicável do Stripe (pk_...), uma chave de mapas restrita ao seu domínio, um ID de estatísticas. A documentação do serviço diz se uma chave é segura para o navegador. Se diz “secreta” ou “somente no servidor”, ou começa com sk_, ela nunca deve estar no seu site.
Se um recurso precisa de um segredo
Se um recurso só funciona com uma chave secreta, um site comum não consegue fazê-lo com segurança sozinho. Suas opções:
- Use um serviço feito para isso: um serviço de formulários para formulários de contato, uma ferramenta de agendamento para consultas, um checkout hospedado para pagamentos. Eles guardam os segredos para você.
- Coloque o segredo atrás de uma pequena função de servidor em algum lugar que ofereça isso, e faça sua página chamá-la.
- Deixe o recurso de lado por enquanto. Um link de e-mail claro é melhor que uma chave vazada.
Pergunte direto à sua IA: “Este site contém alguma chave secreta? Se sim, como podemos fazer isso sem pôr um segredo no navegador?” Ela costuma notar o problema quando perguntada.
Scripts carregados de outro lugar
Muitas páginas feitas com IA puxam scripts de outros sites: um carregador de fontes, um pacote de ícones, estatísticas, um widget de chat. Cada um roda na sua página com poder total. Pode ler o que os visitantes digitam e mudar o que eles veem. Se esse outro site for invadido, a sua página também será.
- Use menos. Pergunte: “Esta página realmente precisa de cada script externo?”
- Fixe a versão. Use
library@1.2.3, não “latest”, para o arquivo não mudar debaixo de você. - Adicione uma verificação de integridade quando a biblioteca publicar uma. O navegador então recusa um arquivo que tenha sido alterado. Fica assim:
<script src="https://cdn.example.com/lib@1.2.3/lib.min.js" integrity="sha384-..." crossorigin="anonymous"></script>
- Confira os widgets. Widgets de estatísticas, chat e agendamento muitas vezes adicionam cookies e rastreamento também. Saiba o que cada um faz e diga isso na sua página de privacidade.
Colocar texto na página com segurança
Se o seu código pega texto da barra de endereço, de uma caixa de formulário ou de um visitante e o coloca na página com innerHTML, um atacante pode inserir código que roda nos navegadores de outras pessoas. Isso se chama cross-site scripting, ou XSS. O hábito seguro é inserir texto simples com textContent, que nunca roda como código.
Find every use of innerHTML, document.write and eval in my site. For each one, say where the text comes from. If it can come from the URL, a form or a visitor, change it to use textContent instead. Tell me what you changed.
Um chatbot na sua página
Uma caixa de chat que conversa com uma IA precisa de uma chave para chamar o serviço de IA. Essa chave pertence a um servidor, nunca à sua página. Mais duas coisas para saber:
- Injeção de prompt. Visitantes podem digitar instruções feitas para enganar o bot e fazê-lo ignorar as suas. Não dá para impedir isso totalmente.
- Então limite o estrago. Não dê ao bot segredos nem ações. Se ele só responde perguntas a partir de texto público, um truque faz pouco mal.
Formulários e dados pessoais
- Colete só o que precisa. Nome e e-mail muitas vezes bastam. Cada campo extra é algo que você precisa proteger.
- Diga para onde vai. Sua página de privacidade deve dizer quem recebe as mensagens e por quê.
- Não crie seu próprio armazenamento. Uma página comum não guarda mensagens com segurança. Use um serviço de formulários ou um embutido no seu host.
No Page Lemon, peça à sua IA para “Adicionar um formulário de contato ao meu site”. As mensagens chegam por e-mail e ficam guardadas na sua conta, sem um serviço de formulários à parte. Os formulários vêm com os planos pagos. Veja Formulários de contato.
Licenças e precisão
- Confira as licenças. Bibliotecas, fontes, ícones e imagens de fora têm termos. Algumas exigem crédito, outras proíbem uso comercial. Peça à sua IA para listar o que você usa e de onde veio.
- Confira os fatos. A IA pode inventar preços, avaliações e afirmações. Quem publicou foi você.
- Quem é dono do trabalho escrito por IA depende do país e ainda está sendo definido. Isto não é aconselhamento jurídico. Se for importante, consulte um profissional.
O que não colar na sua IA
Seu site é público, mas seu chat não foi feito para ser. Não cole nele:
- listas de clientes, pedidos ou mensagens, a menos que você saiba como o serviço de IA trata esses dados;
- senhas, chaves de API ou códigos de login, porque a IA pode escrevê-los no site;
- qualquer coisa que você não imprimiria num panfleto.
Use nomes fictícios e “exemplo@exemplo.com” enquanto cria. Coloque você mesmo os dados reais depois.
Uma checagem de cinco minutos antes de compartilhar o link
Marque estes itens. Ou passe a parte da busca para a sua IA com o prompt abaixo.
0 de 6 concluídos
List every external script, key-like string, innerHTML use, form action and personal detail in my site, with the file and line for each. Don't change anything.
Quando estiver tudo limpo, passe pela checklist de lançamento do site.
Se uma chave ficou pública
Como o Page Lemon ajuda
Sites feitos com IA muitas vezes são publicados por pessoas que nunca precisaram pensar nisso, então há algumas redes de segurança:
- Arquivos
.env,.git,node_modules, source maps e arquivos de chave privada são ignorados e nunca servidos. - Os envios são verificados em busca de tipos conhecidos de chaves secretas e chaves privadas. Se alguma for encontrada, nada daquele envio é publicado, e você é avisado de qual arquivo e linha corrigir.
Essas verificações pegam erros comuns, não todos os segredos. Escolher bem o que publicar ainda é o que protege seus segredos. Mais em Segurança & confiança e Publicar um site.