O recurso anterior te deu as 3 fechaduras imprescindíveis antes de publicar. Este é o próximo nível: a blindagem que os produtos sérios usam. Vamos começar por uma verdade incômoda e libertadora: nada é "impenetrável". Google, Stripe, os bancos — todos podem ser atacados. A meta real não é ser invulnerável; é ser tão caro e chato de atacar que o atacante desista e vá atrás de uma presa mais fácil, e conter o dano quando algo acontece para que uma falha não vire uma catástrofe. É como a sua casa: não existe a impossível de assaltar, existe a que tem grades, alarme, cachorro e câmeras — onde o ladrão olha, calcula o esforço, e vai para a do vizinho. Essa é a meta: ser a casa difícil. Aqui estão as 8 camadas que fazem isso acontecer, em linguagem simples, cada uma com sua analogia e um prompt para pedir à sua IA.
Nada é "impenetrável", e quem te disser o contrário está mentindo. Google, Stripe, os bancos: todos podem ser atacados. Então, para que serve a segurança? A meta real não é ser invulnerável — é ser tão caro e chato de atacar que o atacante desista e vá atrás de uma presa mais fácil. E é conter o dano quando algo acontece, para que uma falha não vire uma catástrofe.
Duas coisas que as pessoas confundem: autenticação é "você é quem diz ser?" (o login), e autorização é "você tem permissão para ISTO em concreto?" (este usuário pode ver este dado?). A regra de ouro: negar por padrão. Tudo está fechado a menos que explicitamente se abra — nunca o contrário. A maioria dos vazamentos acontece porque alguém deixou algo "aberto por padrão" e esqueceu de fechar.
Quero proteger a autenticação e autorização do meu backend com a regra "negar por padrão". Cada endpoint deve nascer fechado e abrir só com justificativa explícita. Configure um guard global que exija autenticação em tudo, e permita marcar como público só o que eu indicar. Para a autorização, verifique permissões por ação, não só por login. Me explique em passos simples o que você fez.
Esta camada é justamente o que vimos no guia anterior (a Fechadura 1). Aqui a elevamos a regra de arquitetura: em um produto multiusuário, RLS não é opcional, é o alicerce.
Meu app é multiusuário (muitos clientes no mesmo banco de dados). Garanta o isolamento total com Row Level Security: ative RLS em TODAS as tabelas com dados de usuários, com políticas que garantam que cada um só acesse o que é seu. Quero que o banco imponha isso mesmo que o código tenha um bug. Use (SELECT auth.uid()) por desempenho e restrinja ao papel authenticated. Me dê o SQL e me explique como testar que um usuário NÃO consegue ver dados de outro.
Adicione rate limiting ao meu backend: um limite de requisições por minuto por usuário e por IP, mais rígido nos endpoints sensíveis (login, cadastro, e os que chamam a IA). Quando o limite for ultrapassado, responda com um erro claro (429) sem derrubar o servidor. Me diga os limites que você recomenda para começar e como ajustá-los.
Antes de uma requisição maliciosa tocar o seu servidor, ela passa por um escudo externo — o Cloudflare é o padrão. Esse escudo absorve os ataques massivos (os DDoS: milhares de máquinas te atacando ao mesmo tempo), filtra bots conhecidos e bloqueia padrões de ataque. Seu servidor fica escondido atrás, sem expor suas portas diretamente. É a primeira linha, a que os grandes usam.
Quero colocar um escudo externo (WAF/CDN como Cloudflare) na frente do meu app. Me guie em passos simples para: passar meu domínio pelo Cloudflare, ativar a proteção DDoS e o firewall de aplicação, e esconder meu servidor de origem para que ninguém bata direto nele. Me diga quais configurações ativar de cara e quais são grátis.
Proteja meus segredos (API keys, senhas, tokens). 1) Tire-os do código e do git: coloque-os em variáveis de ambiente e crie um .gitignore que ignore .env. 2) Se eu guardo chaves dos meus usuários, criptografe-as no banco com uma chave por usuário. 3) Configure o gitleaks como hook antes de cada commit para que ele me barre se eu tentar subir um segredo por acidente. Me explique cada passo de forma simples.
Nunca confie no que o usuário envia. Cada dado que chega ao seu backend é validado contra um esquema rígido antes de tocar em qualquer coisa. Isso bloqueia os ataques clássicos: o SQL injection (que o atacante meta comandos em um formulário para roubar seu banco de dados), a injeção de prompts (que um usuário manipule sua IA para que ela burle suas regras), e os dados malformados que quebram o sistema. A regra: validar em cada borda. Tudo que é externo é suspeito até que se prove o contrário.
Valide TODA a entrada do meu backend com um esquema rígido (use Zod ou equivalente) em cada endpoint, antes de processar qualquer coisa. Rejeite o que não cumprir o esquema. Me proteja especificamente contra SQL injection, injeção de prompts na IA, e dados malformados. Me dê o padrão para aplicar em cada borda e um exemplo em um dos meus endpoints.
Meu app usa IA (que custa dinheiro por uso). Me proteja de que um usuário me sangre os créditos: 1) coloque em cada usuário um orçamento/limite diário de uso de IA, e corte quando atingir, com uma mensagem clara. 2) Registre o consumo por usuário para detectar comportamentos anormais. 3) Me avise se alguém disparar o gasto. Me explique como definir os limites para não afetar o usuário normal.
Você não pode proteger o que não vê. Cada ação importante fica registrada (quem, o quê, quando) em um log imutável que ninguém pode apagar. Se acontece algo estranho, você tem a gravação. E um sistema de alertas te avisa enquanto acontece, não depois. É isso que te deixa dormir tranquilo: se alguém tenta algo, você vê ao vivo.
Adicione auditoria e observabilidade ao meu app: 1) um log imutável que registre quem fez o quê e quando nas ações importantes (login, mudanças de dados, pagamentos), que não possa ser apagado nem editado. 2) Alertas que me avisem em tempo real se acontecer algo suspeito (muitas tentativas de login falhas, gasto anormal, erros em picos). Me diga quais eventos registrar primeiro e como receber os alertas.
Se você quer pedir todas juntas ao arrancar um projeto sério, este prompt resume as 8 camadas para que sua IA as leve em conta desde o alicerce:
Vamos construir este backend com segurança de nível enterprise desde o dia 1, usando "defesa em profundidade" (muitas camadas). Leve em conta estas 8 camadas em tudo que você construir, e me lembre qual está faltando: 1. AUTH: autenticação + autorização com "negar por padrão" (tudo fechado exceto o que eu abrir explícito). 2. ISOLAMENTO: Row Level Security em todas as tabelas (cada usuário só vê o que é seu, imposto pelo banco). 3. RATE LIMITING: limite de requisições por usuário/IP, mais rígido em endpoints sensíveis. 4. ESCUDO EXTERNO: WAF/CDN (Cloudflare) na frente, com proteção DDoS e a origem escondida. 5. SEGREDOS: nada de chaves no código/git; vault + variáveis de ambiente; chaves de usuário criptografadas; gitleaks antes de cada commit. 6. VALIDAÇÃO: validar toda entrada com esquema rígido (Zod) em cada borda; proteção contra SQL injection e injeção de prompts. 7. COST GUARDRAILS: orçamento de IA por usuário com corte automático; detectar consumo anormal. 8. AUDITORIA: log imutável (quem/o quê/quando) + alertas em tempo real. Comece me dizendo quais se aplicam ao meu projeto e em que ordem vamos implementá-las, sem sobre-engenharia para o que eu ainda não preciso.
Join 4,200+ builders. No credit card. Build your first app with AI in minutes.