O banco de dados é o "arquivo/almoxarifado" do sistema — guarda tudo em tabelas (parecidas com planilhas): uma tabela leads com colunas nome, whatsapp; uma tabela content_items, etc.
No projeto do Adriano o banco é o Supabase (um Postgres gerenciado). Ele tem um recurso central para segurança: RLS (Row Level Security).
- Sem RLS: qualquer um com a "chave pública" (a
anon key, que fica visível no código do site) consegue ler todas as linhas de uma tabela. Foi assim que, no Ex. 26/29, aanon keyleu nome + WhatsApp de todos os leads (PII exposta = violação de LGPD). - Com RLS: o banco aplica uma regra por linha: "usuário anônimo só pode ler
content_itemscomstatus = 'active'; leads, ninguém anônimo lê". A defesa fica no dado, não na aplicação.
Por que RLS é tão importante: é defesa em profundidade (0.11). Mesmo que o atacante fure a aplicação (a API), o banco ainda o barra. Se a segurança dependesse só da API, um único furo entregaria tudo. Duas chaves do Supabase, entenda a diferença:
anon key— pública por design, vai no navegador. Só é segura se houver RLS limitando o que ela vê.service_role key— a chave-mestra que ignora o RLS. Nunca pode ir para o cliente. Se vazar (Ex. 4), o atacante lê e escreve tudo.