Checklist de segurança SaaS:5 checagens essenciais
Checklist de segurança SaaS para fundadores não técnicos: 5 checagens que evitam 99% dos desastres, mais um prompt de auditoria pronto para copiar e colar.
Um checklist de segurança SaaS com cinco checagens evita 99% dos desastres de segurança em SaaS: isolamento de dados, senhas seguras, validação de entradas, controle de permissões e sanitização de entradas. Você não precisa virar especialista em segurança para executá-las. Precisa saber que as cinco checagens existem, perguntar ao seu assistente de IA se cada uma está implementada e exigir correções onde não estiver. Este é o checklist completo — o teste de cada checagem, a correção e o prompt pronto para copiar e colar que audita as cinco de uma vez.
Aqui está a verdade que ninguém que te vende "a IA constrói o seu app num fim de semana" menciona: a IA vai construir de bom grado um app inseguro se você nunca pedir segurança. Essas cinco checagens são o que separa apps amadores de apps profissionais — e uma única brecha de segurança pode destruir o seu negócio antes mesmo de ele começar.
O checklist de segurança SaaS em 5 checagens
| # | Checagem | A pergunta a fazer | Resposta aprovada |
|---|---|---|---|
| 1 | Isolamento de dados | Os usuários conseguem ver os dados uns dos outros? | Não — o banco de dados bloqueia, mesmo que o código tenha bugs |
| 2 | Senhas | Como as senhas são armazenadas? | Pelo Supabase Auth, ou com hash irreversível |
| 3 | Validação de entradas | Dados ruins conseguem entrar? | Não — campos obrigatórios, tamanhos, formatos e faixas são todos checados |
| 4 | Permissões | Os usuários conseguem fazer o que não deveriam? | Não — as permissões são checadas antes de cada ação |
| 5 | Prevenção de XSS | A entrada do usuário é segura para exibir? | Sim — tudo o que um usuário digita é sanitizado antes de ser exibido |
Toda checagem segue o mesmo padrão: rode o teste e, se ele falhar, cole o prompt de correção na sua ferramenta de IA. Vamos passar por cada uma.
Checagem 1: Os usuários conseguem ver os dados uns dos outros?
O teste é brutalmente simples. Entre como o Cliente A, mude a URL ou clique por aí e veja se consegue chegar aos dados do Cliente B. Se conseguir, você tem um problemão — do tipo que vira uma violação da LGPD, depois um processo, depois um negócio morto.
A correção é a Row-Level Security: regras que vivem no próprio banco de dados, de modo que, mesmo que haja um bug no seu código, o banco bloqueia o acesso. Diga à sua IA: "Adicione Row-Level Security para que os usuários só vejam os dados da própria organização." Pense nisso como pôr uma fechadura em cada porta de apartamento em vez de confiar que ninguém vai entrar no apartamento errado. Essa checagem merece um artigo só dela, e tem — Row-Level Security explicada para fundadores não técnicos trata disso direito.
Checagem 2: As suas senhas estão realmente seguras?
Pergunte à sua IA: "Como as senhas são armazenadas no banco de dados?" Há duas respostas ruins. "Em texto puro" é um desastre — nunca aceitável. "Criptografadas" parece seguro, mas não é, porque criptografia é reversível. As respostas boas são "com hash via bcrypt ou scrypt" (irreversível) ou, melhor de tudo, "pelo Supabase Auth".
A correção de verdade aqui é uma decisão, não código: não construa o seu próprio sistema de senhas. O Supabase Auth cuida do hash das senhas, da redefinição de senha, da verificação de e-mail, da gestão de sessões e da autenticação multifator — problemas que times profissionais de segurança já resolveram. Construir a sua própria versão é como anotar todas as suas senhas num papel ao lado da porta de entrada em vez de instalar um sistema de segurança de verdade. Se as senhas vazarem, todas as contas ficam comprometidas e os usuários nunca mais confiam em você.
O livroA Revolução do EUpreendedorLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem largar o emprego.Quero o livro →Checagens 3 e 4: dados ruins e permissões quebradas
Checagem 3 — dados ruins conseguem entrar? Tente criar um registro com campos obrigatórios vazios, um nome de 10.000 caracteres, um e-mail em formato inválido ou um número negativo onde só positivo faz sentido. Se o seu app aceitar, você não tem validação — e dados ruins quebram funcionalidades de jeitos estranhos que os seus usuários vão descobrir antes de você. O prompt de correção: "Adicione validação que confira se os campos obrigatórios estão preenchidos, se os campos de texto têm tamanho máximo, se os e-mails têm formato válido, se os números estão em faixas aceitáveis e se as datas são válidas."
Checagem 4 — os usuários conseguem fazer o que não deveriam? Entre como usuário comum, não como admin, e tente excluir outros usuários, mudar configurações de assinatura ou acessar páginas de administração. Se conseguir, o seu sistema de permissões está quebrado — o equivalente digital de dar a cada morador uma chave-mestra de todos os apartamentos. O prompt de correção: "Adicione checagens de permissão: usuários comuns só podem editar as próprias coisas, só admins podem excluir usuários, só donos podem mudar a assinatura — e cheque as permissões antes de permitir as ações." Sem isso, um usuário comum apaga tudo, e você passa a semana emitindo reembolsos para clientes furiosos.
Checagem 5: A entrada do usuário é segura para exibir?
Essa é a mais traiçoeira. Pergunte à sua IA: "Se um usuário inserir HTML ou JavaScript num campo de texto, isso vai ser executado na tela de outros usuários?" Se sim, você tem uma vulnerabilidade de XSS — os seus usuários podem hackear uns aos outros. O Usuário A coloca um script no nome do perfil; o Usuário B abre esse perfil; código malicioso roda na tela do Usuário B e rouba os dados dele. Responsabilidade jurídica, reputação destruída.
O prompt de correção: "Sanitize toda entrada do usuário antes de exibi-la. Remova qualquer HTML, JavaScript ou código perigoso." É criar regras para o que pode passar pela porta — nada explosivo.
A auditoria de segurança de 5 minutos
Você não precisa rodar as checagens uma a uma. Cole isto na sua ferramenta de IA e deixe que ela faça o trabalho:
Audite este app em busca de problemas de segurança:
1. Os usuários conseguem ver dados de outras organizações? (Confira a Row-Level Security)
2. Como as senhas são armazenadas? (Deveria usar o Supabase Auth)
3. A entrada do usuário é validada? (Confira campos obrigatórios, limites de tamanho, validação de formato)
4. As permissões são aplicadas? (Usuários comuns conseguem executar ações de admin?)
5. A entrada do usuário é sanitizada antes de ser exibida? (Confira a prevenção de XSS)
Para cada problema encontrado, explique o risco e como corrigi-lo.
Ela vai te dizer o que está errado. Corrija o que está quebrado, começando por qualquer coisa que envolva isolamento de dados.
Melhor ainda: embuta a segurança na forma como você pede as funcionalidades desde o início. "Construa um app de gestão de contatos" te dá algo que funciona, mas é inseguro. "Construa um app de gestão de contatos com Row-Level Security, Supabase Auth para as senhas, validação de entradas, checagens de permissão e entrada do usuário sanitizada" te dá segurança por padrão. Segurança é uma das cinco dimensões que vale auditar antes do lançamento — a auditoria de qualidade de código completa dá nota a todas elas.
Rode a auditoria. Corrija o que está quebrado. Durma em paz. Construa seguro desde o primeiro dia — porque adaptar a segurança depois de um vazamento é um trabalho que você nunca vai querer.
12 semanasA sua carreira corporativa nunca foi o planoCandidate-se à Aceleradora de EUpreendedores.Candidatar-se →Perguntas frequentes
Preciso ser especialista em segurança para lançar um SaaS?
Não. Você precisa de três coisas: saber que essas 5 checagens existem, perguntar ao seu assistente de IA se cada uma está implementada e exigir correções onde estiverem faltando. As checagens cobrem as falhas por trás de 99% dos desastres — isolamento de dados, senhas, validação, permissões e XSS.
Qual checagem de segurança importa mais?
Isolamento de dados. Se o Cliente A consegue ver os dados do Cliente B, você está diante de uma violação da LGPD e de um processo — o tipo de falha que destrói negócios de uma vez. A Row-Level Security resolve isso no nível do banco de dados, então nem código com bug consegue vazar dados entre clientes.
Devo construir o meu próprio sistema de login e senhas?
Não. Use o Supabase Auth. Ele cuida do hash das senhas, das redefinições, da verificação de e-mail, da gestão de sessões e da autenticação multifator — todos os pontos em que a autenticação caseira dá errado. Armazenamento de senhas feito em casa é como "senhas em texto puro" vira manchete com o nome do seu produto.
Quando devo rodar a auditoria de segurança?
Antes que o seu primeiro usuário real toque no app, e de novo sempre que você adicionar uma funcionalidade que armazena ou exibe dados de usuários. A auditoria leva cinco minutos com o prompt acima — não existe versão do seu roadmap em que pulá-la seja a troca inteligente.
Quão preso você está, de verdade?
Faça o Índice de Sufocamento Corporativo, a avaliação gratuita para saber se você está pronto para ser um EUpreendedor.