Para quem é isto?
Para qualquer pessoa que tenha construído um app com IA e esteja prestes a publicá-lo — você não precisa programar. Se o seu app guarda dados de usuários (contas, mensagens, pedidos, o que for), isto é obrigatório antes de ir para a internet. Cada seção traz uma analogia, o risco, e um prompt para a sua IA configurar. Você só aprova.
Quando isto é feito? (o momento exato)
O momento é claro e não negociável: logo antes de publicar seu app ou entregá-lo a usuários reais. Enquanto você testa sozinho no seu computador, não acontece nada. Mas no segundo em que o seu app está na internet com dados de outras pessoas, sem essas fechaduras você está expondo tudo. E como a IA não faz isso sozinha (ela está pensando em fazer funcionar, não em proteger), cabe a você pedir explicitamente.
A dor que deu origem a este guia
É o pior susto de quem constrói com IA: você lança seu app, alguém muda um número na URL… e vê os dados de OUTRO usuário. Ou pior: uma falha de segurança expõe todo o seu banco de dados. Não dá para sentir na hora de construir —tudo "funciona"— mas é uma bomba-relógio. Estas 3 fechaduras a desarmam em minutos.
Fechadura 1 · RLS (que cada um veja SÓ o que é seu)
Imagine assim
Imagine uma caixa de brinquedos gigante onde todo mundo guarda suas coisas. Sem cadeado, qualquer um pega o que é dos outros. RLS (Row-Level Security, "segurança em nível de linha") é um cadeado mágico que sabe quem é cada um: cada usuário só vê e mexe nos seus próprios dados, mesmo que esteja tudo na mesma caixa.
Sem RLS, um usuário malicioso só precisa mudar um ID na URL ou em uma requisição para ver os dados de outra pessoa. É a vulnerabilidade mais comum em apps com Supabase e PostgreSQL — e a mais fácil de explorar. Por isso é a fechadura #1.
Estou usando Supabase com PostgreSQL. Tenho estas tabelas: [liste suas tabelas e suas colunas de usuário, ex: posts (user_id), comments (post_id, user_id)]. Configure Row-Level Security para que cada usuário só possa ver/editar/apagar seus próprios registros. Siga as melhores práticas oficiais do Supabase: - Ative RLS em TODAS as tabelas (ENABLE ROW LEVEL SECURITY). - Crie políticas SEPARADAS para SELECT, INSERT, UPDATE e DELETE (NÃO use FOR ALL). - IMPORTANTE para o desempenho: envolva a função de usuário como (SELECT auth.uid()), NÃO auth.uid() solto, para que o Postgres a avalie uma única vez por consulta e não uma vez por linha. - Restrinja as políticas ao papel authenticated (TO authenticated), não a public, para que os visitantes anônimos nem toquem na tabela. - NUNCA use user_metadata nas políticas (o usuário pode modificá-lo). - Adicione índices nas colunas que as políticas usam (ex. user_id). - Lembre-se: para que um UPDATE funcione, também é necessária uma política de SELECT. - Me dê o SQL completo pronto para colar no SQL Editor do Supabase, e me explique em uma linha o que cada política faz.
O erro que deixa seu app lentíssimo (o "init-plan trap")
Quase todos os tutoriais dizem para você usar
auth.uid() direto na política. MAS isso faz o Postgres avaliá-lo uma vez para cada linha — em uma tabela de 100.000 linhas, a diferença é entre uma consulta de 5 milissegundos e uma de 5 segundos! O truque (documentado pelo Supabase): escreva como `(SELECT auth.uid())`. Assim é avaliado uma única vez. Por isso o prompt acima pede isso explicitamente.Como sei que já funciona?
- Crie dois usuários de teste no seu app.
- Faça login com o usuário A e crie um registro.
- Faça login com o usuário B: NÃO deve ver o registro de A.
- Verifique o Security Advisor do Supabase: ele te avisa se você deixou alguma tabela sem RLS.
Fechadura 2 · CORS (quem pode chamar sua API)
Imagine assim
CORS é o porteiro da sua API. Ele decide quais páginas web têm permissão de bater na porta. Sem porteiro, qualquer site do mundo pode chamar seu backend a partir do navegador dos seus usuários e se aproveitar da sessão deles.
Configure CORS no meu backend para que SOMENTE meu domínio de produção (https://meu-app.com) e localhost em desenvolvimento possam fazer requisições. - NÃO use "*" como origem permitida em produção. - Permita apenas os métodos que eu realmente uso (ex. GET, POST, PUT, DELETE). - Permita apenas os cabeçalhos que eu preciso. - Me explique exatamente onde colocar cada coisa de acordo com o meu stack: [me diga seu framework/backend].
Erro que você NUNCA deve cometer
Deixar
Access-Control-Allow-Origin: * com credenciais ativadas. É como deixar a porta aberta e colocar um cartaz dizendo "entrem, deixei as chaves dentro". Se a sua IA configurou assim "para funcionar rápido", conserte antes de publicar.Fechadura 3 · Security Headers (instruções de defesa para o navegador)
Imagine assim
Os headers de segurança são as regras da casa que o seu site dá ao navegador na entrada: "não me coloque num frame de outro site", "não carregue scripts de sites que eu não autorizei", "fale comigo só por conexão segura". Sem essas regras, o navegador faz qualquer coisa — e isso abre a porta para ataques comuns.
Adicione os headers de segurança recomendados ao meu app: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Strict-Transport-Security (HSTS) e Permissions-Policy. - Me explique o que cada um faz em uma linha simples. - Me dê a configuração pronta para o meu framework: [me diga qual você usa, ex. Next.js, Express]. - Comece a Content-Security-Policy em modo report-only para não quebrar nada, e me diga como reforçá-la depois. - Me diga como verificar o resultado.
Verifique sua nota de graça
Depois de configurá-los, cole a URL do seu site em securityheaders.com e ele te dá uma nota de A+ a F. É a forma mais rápida de confirmar que ficaram bem colocados — mire em um A.
O hábito · revise antes de cada publicação
Seu checklist de segurança pré-lançamento
- RLS ativado em todas as tabelas com dados de usuários (e testado com 2 contas).
- CORS restrito aos seus domínios, nunca
*com credenciais. - Headers colocados e com nota A em securityheaders.com.
- Seus segredos (.env, chaves de API) NUNCA enviados ao GitHub (veja o guia de GitHub da série).
- Você revisou o Security Advisor do Supabase e não restam avisos em vermelho.
Combine com o C-A-R
A segurança é justamente o tipo de coisa que o modo construtor da IA deixa passar. Por isso ela se encaixa perfeitamente na fase de auditar do [protocolo C-A-R](/recursos/protocolo-car-construir-sin-bugs): quando você auditar antes de publicar, coloque estas 3 fechaduras na lista. Construir pensa em fazer funcionar; auditar pensa em como atacam.
No NeuralOS, a segurança vem de fábrica
No NeuralOS, os apps que você constrói já nascem com essas proteções colocadas por padrão — RLS, origens restritas e headers — sem que você precise se lembrar de configurá-las. A ideia é que você não consiga publicar algo inseguro por esquecimento. A visão já está no caminho que estamos construindo.