Guias de Segurança
Adicionou um login e achou que estava seguro? — autenticação vs autorização
Autenticação (quem) vs autorização (o que você pode fazer): um login sem dados restritos ao dono gera 'logado = vê todos os dados'. Por que acontece e como se defender.
"Adicionei um login, então agora está protegido" — essa é uma suposição perigosa. Login (autenticação) e permissões (autorização) são coisas diferentes, e confundi-las leva a um incidente em que todo mundo que faz login consegue ver todos os dados, inclusive os de outras pessoas. Sem passos de ataque aqui — apenas como isso acontece e como se defender.
Autenticação e autorização são coisas diferentes
São facilmente confundidas, mas seus papéis são completamente distintos.
Só autenticação (o erro comum)
- pensar "consegue logar = seguro"
- tratar as leituras de dados pós-login como iguais para todos
- resultado: todo mundo que faz login alcança todos os dados
Autenticação + autorização (como deveria ser)
- a autenticação confirma "quem"
- a autorização limita a "apenas os dados que a pessoa pode tocar"
- as leituras de dados são sempre restritas ao dono
A autenticação é "a conferência de identidade na entrada"; a autorização é "controlar em quais salas você pode entrar". Um login só garante a primeira. "Quem pode tocar em quais dados" é algo que você precisa escrever à parte.
Como "vê todos os dados" acontece em apps reais
No campo, a mesma falha aparece repetidamente em sistemas independentes, feitos à mão. Um app pessoal de tarefas/notas, ou um pequeno sistema de gestão de produtos/pedidos (com integrações de API externas) — a causa era a mesma sobreposição de duas falhas.
① O registro está aberto (e em duas rotas)
Scaffolds de autenticação (coisas como Breeze/Jetstream do Laravel) frequentemente já vêm com a página de registro pública por padrão. E quando a rota de registro é duplicada entre a biblioteca de UI e o pacote de autenticação, fechar uma ainda deixa /register. Um estranho que sabe a URL pode se cadastrar.
② A autenticação existe mas a autorização não (falta o escopo de dono)
A tabela de dados não tem coluna de dono (user_id), ou as consultas de listar/ler/atualizar/excluir não estão restritas ao usuário atual. Então "logado = acesso a todos os dados." Se o app faz login automático logo após o cadastro, um estranho cai sobre a lista de dados de outra pessoa no momento em que se registra.
Resultado: o incidente authn ≠ authz
A entrada (login) está lá, mas as chaves das salas (autorização) não. Como o estranho se comporta como "um usuário devidamente logado", quase não há sequer um rastro de acesso não autorizado.
O raio de destruição é maior quanto mais dados de negócio estão envolvidos (registros de clientes, pedidos, chaves de API de integração podem todos ser afetados). E um sistema diferente construído do mesmo jeito provavelmente tem a mesma falha.
Como se defender
Sempre restrinja os dados ao dono
Limite toda leitura e escrita a "as próprias linhas do usuário logado". Imponha a condição de dono em todas as operações de ler/atualizar/excluir por meio de um global scope do ORM ou de uma política de autorização (policy/gate). Se a tabela não tem coluna de dono, redesenhe isso primeiro.
Feche o registro que você não precisa — e desconfie de rotas duplicadas
Desative o cadastro em apps pessoais/internos. Meça de fato, via HTTP, que /register e afins retornam 404, e verifique ambas as rotas de registro: a da biblioteca de UI e a do pacote de autenticação.
Defesa em profundidade nas superfícies administrativas
Para uso interno/administrativo, não confie só na autenticação — adicione camadas de restrição de IP, Basic auth e afins. Se uma parede cair, a próxima detém.
Logs de auditoria e de acesso *antes* de um incidente
Sem "quem, quando, de qual IP, fez o quê", você não consegue reconstruir "o que foi visto" depois. No mínimo, mantenha logs de auditoria de sucesso/falha de login e retenha/rotacione os logs de acesso web.
Detecte novos cadastros e anomalias
A lição central aqui é "passou despercebido por muito tempo". Adicione formas de notar rápido — notificações no registro de novo usuário, inventários periódicos de usuários/dados. Sem detecção, a falha fica silenciosamente aberta.
A visão deste site: uma biblioteca só garante 'quem'
Uma biblioteca de autenticação cuida de "quem" — nada além disso. "O que essa pessoa pode fazer" não existe a menos que você, o projetista, escreva. E — uma falha estrutural encontrada em um sistema provavelmente está em outros sistemas construídos do mesmo jeito. Não corrija um e pare; audite as construções do mesmo formato em toda a linha. Quando você não consegue saber se algo foi lido, a postura correta é tratá-lo como lido e revogar/rotacionar quaisquer segredos expostos.
Leia a seguir
- Glossário: o que é IDOR (controle de acesso quebrado) (o clássico: informe o ID de outra pessoa e alcance os dados dela)
- Aplique: segurança por framework (onde escrever a autorização em cada framework)
- Relacionado: mantenha segredos fora de diretórios públicos (verificando exposição de token/credenciais/.env)
- Fundamentos: protegendo segredos, do zero / base: a checklist mínima de segurança
Fontes
- OWASP Top 10 (2021) A01: Broken Access Control: owasp.org
- OWASP Authorization Cheat Sheet: cheatsheetseries.owasp.org
FAQ
QQual a diferença entre autenticação e autorização?
A autenticação verifica quem você é (login). A autorização decide o que você pode fazer (permissões). Numa analogia, a autenticação é a conferência de identidade na entrada do prédio; a autorização controla em quais salas você pode entrar. Adicionar um login implementa apenas a autenticação — a autorização (quem pode tocar em quais dados) é algo que você precisa escrever à parte. Confunda as duas e você acaba com 'todo mundo que faz login consegue ver todos os dados'.
QExiste um login — então por que todos conseguem ver todos os dados?
Porque a consulta aos dados não está restrita a 'apenas as linhas do próprio usuário logado'. Esqueça a condição de dono (user_id) em qualquer operação de listar/ler/atualizar/excluir e, uma vez logado, todas as linhas voltam — inclusive as de outras pessoas. É uma falha de design independente de haver ou não autenticação, e é o clássico Broken Access Control que o OWASP coloca em primeiro lugar.
QPara uma ferramenta pessoal ou app interno, deixar o registro aberto não tem problema, certo?
É perigoso. Muitos scaffolds de autenticação já vêm com o registro (por exemplo, /register) público por padrão. Se um estranho souber a URL, ele pode se cadastrar e, sem autorização, cai direto sobre os dados internos. As rotas de registro às vezes são duplicadas (tanto na biblioteca de UI quanto no pacote de autenticação), então fechar uma não fecha a outra. Desative o registro que você não precisa e adicione camadas de defesa, como restrições de IP nas superfícies administrativas.