Segurança com Spring Security

A segurança escrita à mão nos controladores sempre falha da mesma forma. Adiciona-se um teste no início de cada método sensível — if (session.getAttribute("user") == null) return "redirect:/login"; — e isso funciona, até o dia em que um novo método é escrito sem esse teste. A falha não está no código de segurança: está na sua ausência em algum lugar, e nada sinaliza essa ausência.

Essa é a diferença de natureza entre um controle por lista de permissões e um controle por lista de bloqueios. Proteger cada tela individualmente é decidir que uma tela é pública por padrão. Ora, as telas se multiplicam mais rápido que as revisões de código, e um esquecimento não provoca nenhum erro: a página funciona, apenas está acessível a todos.

O Spring Security inverte esse padrão. Ele se insere antes do DispatcherServlet, na forma de uma cadeia de filtros de servlet, e aplica uma política declarada em um único lugar. Uma requisição para uma URL não prevista pela política não chega a nenhum controlador: ela é recusada pela infraestrutura. Adicionar uma tela, portanto, não cria uma brecha — na pior das hipóteses, ela fica inacessível, o que é percebido imediatamente.