Lista de Verificação de Segurança para Apps Criadas com IA: O Que Verificar Antes do Lançamento

Antes de pessoas reais usarem uma app que construiu com IA, verifique sete coisas: cada página e cada API confirma quem é o utilizador e o que pode fazer; as chaves secretas ficam no servidor, nunca no navegador ou no chat; todos os dados são validados no servidor; cada utilizador só consegue aceder aos seus próprios registos; o início de sessão e os endpoints dispendiosos têm limites de pedidos; as dependências estão atualizadas; e consegue restaurar os seus dados se algo correr mal. A lista abaixo transforma cada um destes pontos em testes concretos que pode fazer sem ler código.

Os criadores de apps com IA são bons a fazer funcionar as funcionalidades. Não são automaticamente cuidadosos, porque “cuidadoso” raramente está no pedido. A maioria dos problemas abaixo vem de coisas que ninguém pediu, por isso a solução costuma ser pedi-las.

Como usar esta lista

Percorra-a por ordem e, para cada item, faça duas coisas: peça à IA que garanta que está tratado e teste você mesmo. A IA consegue escrever uma verificação de permissões; só um teste lhe diz que funciona. Os itens estão marcados assim:

• Obrigatório — faça isto antes de qualquer outra pessoa usar a app.
• Recomendado — faça isto antes de ter utilizadores ou dados reais.
• Mais tarde — vale a pena fazer à medida que a app cresce.

Se tiver apenas uma hora, faça todos os itens Obrigatórios.

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

A autenticação significa confirmar quem alguém é, normalmente através do início de sessão. Veja o que é a autenticação para o básico e como adicionar início de sessão à sua app para as opções.

• Obrigatório: Cada página que mostra dados privados exige início de sessão. Teste: termine a sessão e cole o URL de uma página privada diretamente no navegador.
• Obrigatório: Cada endpoint de API por trás dessas páginas também exige início de sessão, e não apenas a página. Teste: termine a sessão, abra o separador de rede do navegador e repita um pedido que a app fez enquanto estava autenticado.
• Obrigatório: As palavras-passe são guardadas com um algoritmo lento de hash, nunca em texto simples. As diretrizes da OWASP para armazenamento de palavras-passe recomendam primeiro o Argon2id, com scrypt, bcrypt ou PBKDF2 como alternativas. Pergunte: “Como são guardadas as palavras-passe?”
• Recomendado: Os links de redefinição de palavra-passe expiram e funcionam apenas uma vez.
• Recomendado: Os cookies de sessão estão marcados como Secure, HttpOnly e SameSite, e terminar a sessão encerra a sessão no servidor.
• Mais tarde: Ofereça autenticação de dois fatores, ou início de sessão através de um fornecedor que a tenha.

Verifique cada rota de API e página que devolve dados de utilizadores. Cada uma deve rejeitar pedidos de utilizadores que não estejam autenticados, no servidor, e não apenas no código da página. Liste as rotas que verificou.

2. Autorização: o que lhes é permitido fazer?

A autorização é o passo a seguir ao início de sessão: decidir o que este utilizador em particular pode ver e alterar. É aqui que as apps criadas com IA costumam ter falhas graves, porque a app parece correta (o painel de cada utilizador só mostra os seus próprios dados) enquanto o servidor entrega de bom grado os dados de qualquer pessoa se lhe forem pedidos diretamente.

• Obrigatório: Cada leitura, atualização e eliminação verifica, no servidor, que o registo pertence ao utilizador atual (ou à sua equipa).
• Obrigatório: Teste: crie duas contas, A e B. Como A, abra um dos registos de A e anote o ID no URL ou no pedido de rede. Inicie sessão como B e peça esse mesmo ID. B deve receber um erro, e não os dados de A.
• Obrigatório: As páginas de administração e os endpoints de API de administração verificam a função do utilizador no servidor. Esconder a ligação de administração não é proteção.
• Obrigatório: Os utilizadores não conseguem alterar a sua própria função, preço, saldo ou campos de proprietário editando o pedido. Teste: no separador de rede, veja o que envia uma atualização de perfil. Se incluir campos como role ou isAdmin, peça à IA que os ignore quando vêm do cliente.
• Recomendado: Os IDs nos URLs são difíceis de adivinhar (IDs aleatórios em vez de 1, 2, 3). Isto não substitui as verificações de permissões, mas limita o dano quando uma falta.

Para cada endpoint que lê ou altera um registo, verifique no servidor que o utilizador autenticado é o proprietário ou tem permissão para aceder. Devolva 404 se não tiver. Depois, mostre-me como testaria isto com duas contas.

3. Acesso ao nível da linha na base de dados

“Acesso ao nível da linha” significa que cada linha de uma tabela (uma marcação, uma fatura) só é visível para os utilizadores a quem pertence. Há duas formas comuns de o impor:

Ambas podem ser bem feitas. O que importa:

• Obrigatório: Se o navegador fala diretamente com a base de dados (alguns produtos de bases de dados alojadas permitem isto), as regras ao nível da linha estão ativas em todas as tabelas. Sem elas, qualquer pessoa com a chave pública pode ler a tabela inteira.
• Obrigatório: As consultas filtram pelo utilizador ou equipa atual, e não por um ID que o navegador envia.
• Recomendado: Os dados partilhados (os projetos de uma equipa) têm uma regra clara sobre quem faz parte da equipa, aplicada num único sítio.

4. Segredos e chaves de API

Uma chave de API é uma palavra-passe para um serviço. O Stripe, o email e os fornecedores de IA usam todos chaves. Para contexto, veja o que são variáveis de ambiente e segredos.

• Obrigatório: As chaves são guardadas nas variáveis de ambiente ou nos segredos do projeto, nunca escritas no código.
• Obrigatório: As chaves que podem gastar dinheiro ou ler dados privados são usadas apenas no servidor. Teste: abra o seu site em produção, veja o código-fonte da página e os ficheiros JavaScript nas ferramentas de programador, e procure o início da sua chave (por exemplo sk_). Não deve aparecer.
• Obrigatório: As chaves nunca foram coladas no chat, num repositório público ou numa captura de ecrã. Se alguma foi, substitua-a no fornecedor (crie uma nova e elimine a antiga).
• Recomendado: Use chaves restritas ou com âmbito limitado onde o fornecedor as oferecer. O Stripe, por exemplo, recomenda chaves restritas que só tenham as permissões de que a sua integração precisa.
• Recomendado: As chaves de teste e as de produção são separadas, e a app em produção só usa chaves de produção quando estiver pronto.

Algumas chaves foram concebidas para serem públicas, como a chave publicável do Stripe (pk_…) ou uma chave de mapas restrita ao seu domínio. A regra aplica-se às chaves que concedem poder, e não a todas as cadeias que parecem chaves.

5. Validação de dados

Qualquer coisa que um utilizador envie (campos de formulário, uploads de ficheiros, parâmetros de URL) pode ser qualquer coisa, e não apenas o que o seu formulário permite.

• Obrigatório: A validação acontece no servidor, e não apenas no navegador. As verificações do navegador servem para conveniência; qualquer pessoa as consegue contornar.
• Obrigatório: As consultas à base de dados usam parâmetros, e não texto construído a partir dos dados do utilizador (isto evita a injeção de SQL). Peça à IA que confirme.
• Obrigatório: O texto que os utilizadores escrevem é mostrado como texto, e não executado como HTML. Teste: escreva <b>olá</b> como nome. Deve ver as etiquetas, e não um texto em negrito.
• Recomendado: Os uploads de ficheiros verificam o tipo e o tamanho, e os ficheiros enviados não são servidos a partir do domínio principal da app como páginas executáveis.
• Recomendado: Os erros mostrados aos utilizadores são simples (“Algo correu mal”); os erros detalhados vão apenas para os registos do servidor.
• Recomendado: Os webhooks de serviços como o Stripe verificam a assinatura do fornecedor antes de agir. Veja o que é um webhook.

Acrescente validação no servidor a cada formulário e endpoint de API: campos obrigatórios, comprimentos, formatos e valores permitidos. Rejeite tudo o resto com uma mensagem clara. Não mostre aos utilizadores detalhes internos de erros.

6. Limites de pedidos e abuso

Um limite de pedidos restringe quantos pedidos alguém pode fazer num período. Sem eles, qualquer pessoa pode tentar adivinhar palavras-passe o dia inteiro, inundar o seu formulário de registo ou fazer subir a fatura de uma API paga.

• Obrigatório: O início de sessão, o registo e a redefinição de palavra-passe têm limites de pedidos por endereço IP e por conta.
• Obrigatório: Qualquer coisa que lhe custe dinheiro por chamada (pedidos a modelos de IA, SMS, email) tem um limite por utilizador e exige início de sessão.
• Recomendado: Os formulários públicos (contacto, lista de espera) têm proteção contra spam: um limite de pedidos, um campo oculto de isco ou um CAPTCHA.
• Recomendado: Defina limites de gastos ou alertas nos seus fornecedores pagos, para que um erro ou um atacante não consiga produzir uma fatura ilimitada.

7. Dependências

As apps são construídas a partir de pacotes de código aberto, e os pacotes por vezes têm vulnerabilidades conhecidas.

• Recomendado: Peça à IA que verifique vulnerabilidades conhecidas (para projetos JavaScript, npm audit ou o equivalente do seu gestor de pacotes) e atualize o que estiver afetado.
• Recomendado: Remova os pacotes que a app já não usa.
• Recomendado: Desconfie de pacotes com muito poucos utilizadores ou com nomes que parecem erros de escrita de pacotes populares.
• Mais tarde: Volte a verificar a cada um ou dois meses, ou ative alertas automáticos se o seu código estiver no GitHub.

8. Cópias de segurança e recuperação

A segurança inclui conseguir recuperar de erros, sejam seus, da IA ou de um atacante.

• Obrigatório: Saiba onde estão os seus dados e se têm cópia de segurança. Não presuma; verifique a documentação do seu fornecedor de alojamento.
• Recomendado: Guarde uma exportação periódica sua dos dados importantes (por exemplo, uma funcionalidade de exportação para CSV ou um dump da base de dados), num sítio separado.
• Recomendado: Guarde o seu código num sistema de controlo de versões, para poder restaurar qualquer versão.
• Recomendado: As ações destrutivas (eliminar conta, eliminar projeto) pedem confirmação, e considere uma “eliminação suave” que possa ser desfeita durante algum tempo.
• Mais tarde: Teste de facto uma restauração uma vez. Uma cópia de segurança que nunca restaurou é uma esperança, não um plano.

9. Antes do lançamento

• Obrigatório: O site em produção usa HTTPS em todo o lado.
• Obrigatório: Os dados de exemplo, as contas de teste e as páginas de depuração do desenvolvimento foram removidos.
• Recomendado: Uma política de privacidade indica que dados recolhe e porquê, o que é obrigatório em muitos locais se recolher dados pessoais. Não declare certificações (SOC 2, HIPAA) que não tenha.
• Recomendado: Tem uma forma de ser contactado sobre problemas de segurança, e sabe como substituir rapidamente cada chave.

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

Quando pedir uma revisão profissional

Uma lista de verificação apanha erros comuns; não substitui um especialista. Considere pagar uma revisão se processar números de cartões diretamente, em vez de através de um checkout alojado, se guardar dados de saúde, financeiros ou de crianças, se vender a empresas que pedem questionários de segurança, ou se uma fuga de dados lhe causasse um prejuízo sério. Ter o seu código exportável facilita muito essa revisão.

Segurança ao criar com o Mythex

O Mythex não inclui um painel de análise de segurança, por isso a lista acima é o processo a seguir. Algumas coisas ajudam:

• Segredos do projeto. Guarde as chaves em definições do projeto → Segredos, ou através do cartão de segredos que o agente mostra no chat, para que fiquem fora do seu código e das mensagens. Depois de alterar um segredo de uma app em produção, publique novamente.
• Modos Plano e Pergunta. Peça ao agente que reveja as permissões sem editar: “No modo Pergunta, liste cada rota de API e a verificação de permissões que faz.”
• /test faz com que o agente clique pela sua pré-visualização como um utilizador, útil para o teste de duas contas da secção 2.
• Pontos de controlo permitem-lhe reverter uma alteração que partiu algo.

Veja Segurança para apps que cria e Variáveis de ambiente e segredos na documentação. Se estiver a acrescentar contas de utilizadores a seguir, leia como adicionar início de sessão à sua app.

Perguntas