Proteção de APIs REST

Pegue a configuração de uma aplicação web clássica, aponte um cliente JavaScript para ela e observe: em vez de um 401 limpo, sua chamada fetch recebe um 302 para uma página de login em HTML. O cliente, que esperava JSON, tenta interpretar HTML e falha com uma mensagem incompreensível. Nada está quebrado, no entanto: o Spring Security faz exatamente o que lhe foi pedido, ou seja, se comportar como se um navegador estivesse seguindo um fluxo de login.

Esse é o primeiro ajuste a fazer: uma API não redireciona, ela responde com um código. O segundo diz respeito ao estado. Uma aplicação com sessão armazena a identidade no servidor e a recupera por meio de um cookie; uma API stateless exige que cada requisição carregue sua própria prova de identidade. Os dois modelos funcionam, mas não têm as mesmas vulnerabilidades, e as proteções adequadas a um não servem para o outro.

É aí que ocorrem os dois erros mais comuns da área. O primeiro é copiar csrf.disable() sem se perguntar o que tornava essa proteção necessária — e desativá-la também nas partes da aplicação que usam cookies. O segundo é tratar o CORS como um mecanismo de segurança, quando ele não é, e abrir um acesso achando que o está controlando.