Checklist de segurança para apps criados com IA: o que verificar antes do lançamento

Antes que pessoas reais usem um app que você criou com IA, verifique sete coisas: cada página e cada API confere quem é o usuário e o que ele pode fazer; as chaves secretas ficam no servidor, nunca no navegador ou no chat; todas as entradas são validadas no servidor; cada usuário só acessa os próprios registros; o login e os endpoints caros têm limite de requisições; as dependências estão atualizadas; e você consegue restaurar seus dados se algo der errado. O checklist abaixo transforma cada uma dessas coisas em testes específicos que você pode executar sem ler código.

Os construtores de apps com IA são bons em fazer funcionalidades funcionarem. Eles não são cuidadosos automaticamente, porque “cuidado” raramente está no prompt. A maioria dos problemas abaixo vem de coisas que ninguém pediu, então a solução geralmente é pedir.

Como usar este checklist

Siga-o em ordem e, para cada item, faça duas coisas: peça à IA que garanta que o item está tratado e teste você mesmo. A IA pode escrever uma verificação de permissão; só um teste mostra que ela funciona. Os itens são marcados assim:

• Obrigatório — faça isso antes que qualquer outra pessoa use o app.
• Recomendado — faça isso antes de ter usuários reais ou dados reais.
• Depois — vale a pena conforme o app cresce.

Se você tem apenas uma hora, faça todos os Obrigatórios.

1. Autenticação: quem é esta pessoa?

Autenticação significa confirmar quem alguém é, normalmente pelo login. Veja o que é autenticação para o básico e como adicionar login ao seu app para as opções.

• Obrigatório: toda página que mostra dados privados exige login. Teste: saia da conta e cole a URL de uma página privada diretamente no navegador.
• Obrigatório: todo endpoint de API por trás dessas páginas também exige login, não apenas a página. Teste: saia da conta, abra a aba de rede do navegador e repita uma requisição que o app fez enquanto você estava logado.
• Obrigatório: senhas são armazenadas com hash usando um algoritmo lento de hash de senhas, nunca em texto puro. O guia de armazenamento de senhas da OWASP recomenda Argon2id em primeiro lugar, com scrypt, bcrypt ou PBKDF2 como alternativas. Pergunte: “Como as senhas são armazenadas?”
• Recomendado: links de redefinição de senha expiram e funcionam apenas uma vez.
• Recomendado: cookies de sessão são marcados como Secure, HttpOnly e SameSite, e sair da conta encerra a sessão no servidor.
• Depois: ofereça autenticação de dois fatores, ou login por um provedor que a tenha.

Verifique cada rota de API e página que retorna dados de usuário. Cada uma deve rejeitar requisições de usuários que não estão logados, no servidor, e não apenas no código da página. Liste as rotas que você verificou.

2. Autorização: o que essa pessoa pode fazer?

Autorização é a etapa depois do login: decidir o que este usuário específico pode ver e alterar. É aqui que apps criados com IA mais costumam ter falhas graves, porque o app parece correto — o painel de cada usuário só mostra os dados dele — enquanto o servidor entrega de bom grado os dados de qualquer pessoa se alguém pedir diretamente.

• Obrigatório: toda leitura, atualização e exclusão verifica, no servidor, que o registro pertence ao usuário atual (ou à equipe dele).
• Obrigatório: teste: crie duas contas, A e B. Como A, abra um dos registros de A e anote o ID na URL ou na requisição de rede. Entre como B e solicite esse mesmo ID. B deve receber um erro, não os dados de A.
• Obrigatório: páginas administrativas e endpoints administrativos verificam o papel do usuário no servidor. Esconder o link de administração não é proteção.
• Obrigatório: usuários não conseguem alterar o próprio papel, preço, saldo ou campos de dono editando a requisição. Teste: na aba de rede, veja o que uma atualização de perfil envia. Se incluir campos como role ou isAdmin, peça à IA para ignorá-los vindos do cliente.
• Recomendado: IDs em URLs são difíceis de adivinhar (IDs aleatórios em vez de 1, 2, 3). Isso não substitui verificações de permissão, mas limita o estrago quando uma delas está ausente.

Para cada endpoint que lê ou altera um registro, verifique no servidor se o usuário logado é dono dele ou tem permissão de acesso. Retorne 404 se não tiver. Depois mostre como você testaria isso com duas contas.

3. Acesso em nível de linha no banco de dados

“Acesso em nível de linha” significa que cada linha de uma tabela (uma reserva, uma fatura) só fica visível para os usuários a que pertence. Há duas formas comuns de garantir isso:

Ambas podem ser bem feitas. O que importa:

• Obrigatório: se o navegador fala diretamente com o banco de dados (alguns produtos de banco hospedado permitem isso), as regras de nível de linha estão ativadas em toda tabela. Sem elas, qualquer pessoa com a chave pública pode ler a tabela inteira.
• Obrigatório: as consultas filtram pelo usuário ou equipe atual, e não por um ID enviado pelo navegador.
• Recomendado: dados compartilhados (projetos de uma equipe) têm uma regra clara sobre quem faz parte da equipe, aplicada em um único lugar.

4. Segredos e chaves de API

Uma chave de API é uma senha para um serviço. Stripe, e-mail e provedores de IA usam todos elas. Para entender o básico, veja o que são variáveis de ambiente e segredos.

• Obrigatório: as chaves ficam nas variáveis de ambiente ou segredos do projeto, nunca escritas no código.
• Obrigatório: chaves que podem gastar dinheiro ou ler dados privados são usadas somente no servidor. Teste: abra seu site no ar, veja o código-fonte da página e os arquivos JavaScript nas ferramentas de desenvolvedor e procure o início da sua chave (por exemplo sk_). Ela não deve aparecer.
• Obrigatório: chaves nunca foram coladas no chat, em um repositório público ou em uma captura de tela. Se foram, gere uma nova no provedor (crie uma nova e exclua a antiga).
• Recomendado: use chaves restritas ou com escopo quando o provedor oferecer. A Stripe, por exemplo, recomenda chaves restritas que tenham apenas as permissões que sua integração precisa.
• Recomendado: chaves de teste e de produção são separadas, e o app em produção só usa chaves de produção quando você estiver pronto.

Algumas chaves foram feitas para serem públicas — a chave publicável da Stripe (pk_…) ou uma chave de mapas restrita ao seu domínio. A regra vale para chaves que concedem poder, e não para toda string que se parece com uma chave.

5. Validação de entradas

Tudo o que um usuário envia — campos de formulário, uploads de arquivos, parâmetros de URL — pode ser qualquer coisa, não apenas o que o seu formulário permite.

• Obrigatório: a validação acontece no servidor, não apenas no navegador. As verificações do navegador são para conveniência; qualquer pessoa pode pulá-las.
• Obrigatório: consultas ao banco usam parâmetros, e não texto montado com a entrada do usuário (isso evita injeção de SQL). Peça à IA para confirmar.
• Obrigatório: o texto digitado pelos usuários é exibido como texto, não executado como HTML. Teste: digite <b>olá</b> como seu nome. Você deve ver as tags, não um texto em negrito.
• Recomendado: uploads de arquivos verificam tipo e tamanho, e os arquivos enviados não são servidos a partir do domínio principal do seu app como páginas executáveis.
• Recomendado: erros mostrados aos usuários são simples (“Algo deu errado”); erros detalhados vão apenas para os logs do servidor.
• Recomendado: webhooks de serviços como a Stripe verificam a assinatura do provedor antes de agir. Veja o que é um webhook.

Adicione validação no servidor a todo formulário e endpoint de API: campos obrigatórios, tamanhos, formatos e valores permitidos. Rejeite o resto com uma mensagem clara. Não mostre detalhes internos de erro aos usuários.

6. Limites de requisições e abuso

Um limite de requisições restringe quantas requisições alguém pode fazer em um período. Sem eles, qualquer pessoa pode tentar adivinhar senhas o dia inteiro, inundar seu formulário de cadastro ou gerar uma conta alta em uma API paga.

• Obrigatório: login, cadastro e redefinição de senha têm limite de requisições por endereço IP e por conta.
• Obrigatório: tudo que custa dinheiro por chamada — requisições a modelos de IA, SMS, e-mail — tem um limite por usuário e exige login.
• Recomendado: formulários públicos (contato, lista de espera) têm proteção contra spam: um limite de requisições, um campo oculto armadilha (honeypot) ou um CAPTCHA.
• Recomendado: defina limites de gasto ou alertas nos provedores pagos, para que um bug ou um atacante não consiga gerar uma conta ilimitada.

7. Dependências

Apps são construídos com pacotes de código aberto, e esses pacotes às vezes têm vulnerabilidades conhecidas.

• Recomendado: peça à IA para verificar vulnerabilidades conhecidas (em projetos JavaScript, npm audit ou o equivalente do seu gerenciador de pacotes) e atualizar o que estiver afetado.
• Recomendado: remova pacotes que o app não usa mais.
• Recomendado: desconfie de pacotes com poucos usuários ou com nomes que parecem erros de digitação de pacotes populares.
• Depois: verifique novamente a cada um ou dois meses, ou ative alertas automáticos se seu código estiver no GitHub.

8. Backups e recuperação

Segurança inclui conseguir se recuperar de erros — seus, da IA ou de um atacante.

• Obrigatório: saiba onde seus dados estão e se têm backup. Não presuma; confira a documentação do seu host.
• Recomendado: mantenha uma exportação periódica própria dos dados importantes (por exemplo, um recurso de exportação em CSV ou um dump do banco), guardada em outro lugar.
• Recomendado: mantenha seu código sob controle de versão, para que qualquer versão possa ser restaurada.
• Recomendado: ações destrutivas (excluir conta, excluir projeto) pedem confirmação, e considere uma “exclusão reversível” que pode ser desfeita por um tempo.
• Depois: teste de fato uma restauração pelo menos uma vez. Um backup que você nunca restaurou é uma esperança, não um plano.

9. Antes do lançamento

• Obrigatório: o site no ar usa HTTPS em todas as páginas.
• Obrigatório: dados de exemplo, contas de teste e páginas de depuração do desenvolvimento foram removidos.
• Recomendado: uma política de privacidade informa quais dados você coleta e por quê — exigida em muitos lugares se você coleta dados pessoais. Não afirme certificações (SOC 2, HIPAA) que você não tem.
• Recomendado: você tem um meio de ser contatado sobre problemas de segurança e sabe como gerar novamente qualquer chave rapidamente.

Para uma revisão pré-lançamento mais ampla, além da segurança, veja como levar um protótipo de IA para produção.

Quando procurar uma revisão profissional

Um checklist pega erros comuns; ele não substitui um especialista. Considere pagar por uma revisão se você processa números de cartão diretamente em vez de usar um checkout hospedado, armazena dados de saúde, financeiros ou de crianças, vende para empresas que pedem questionários de segurança, ou seria seriamente prejudicado por um vazamento. Ter seu código exportável facilita muito essa revisão.

Segurança ao construir no Mythex

O Mythex não inclui um painel de varredura de segurança, então o checklist acima é o processo a seguir. Algumas coisas ajudam:

• Segredos do projeto. Guarde as chaves em configurações do projeto → Segredos, ou pelo cartão de segredos que o agente mostra no chat, para que fiquem fora do seu código e das suas mensagens. Depois de alterar um segredo de um app no ar, publique novamente.
• Modos Plan e Ask. Peça ao agente para revisar permissões sem editar: “No modo Ask, liste cada rota de API e a verificação de permissão que ela faz.”
• /test faz o agente percorrer sua prévia como um usuário — útil para o teste das duas contas da seção 2.
• Checkpoints permitem reverter uma alteração que quebrou algo.

Veja Segurança para apps que você cria e Variáveis de ambiente e segredos na documentação. Se você está adicionando contas de usuário a seguir, leia como adicionar login ao seu app.

Perguntas