É um excesso de engenharia se eu adicionar proteção contra as ações intencionais de um usuário (para dizer o mínimo), se o dano que o usuário pode incorrer não está relacionado ao meu código?
Para esclarecer, estou expondo um serviço JSON RESTful simples como este:
GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item
O serviço em si não se destina a ser usado através de um navegador, mas apenas a partir de aplicativos de terceiros, controlados pelo usuário (como aplicativos de telefone, aplicativo de desktop etc.). Além disso, o serviço em si deve ser sem estado (ou seja, sem sessão).
A autenticação é feita com autenticação básica sobre SSL.
Estou falando de um possível comportamento "prejudicial" como este:
O usuário digita o URL GET em um navegador (sem motivo, mas ...). O navegador solicita a autenticação básica, processa-a e armazena a autenticação para a sessão de navegação atual. Sem fechar o navegador, o usuário visita um site mal-intencionado, que possui um javascript CSRF / XSRF malicioso que faz um POST para o nosso serviço.
O cenário acima é altamente improvável e sei que, do ponto de vista comercial, não devo me preocupar muito. Mas, para melhorar a situação, você acha que, se o nome de usuário / senha também forem necessários nos dados do JSON POST, isso ajudará?
Ou devo abandonar completamente a autenticação básica, livrar-me do GET e usar apenas POST / PUT com informações de autorização? Como as informações recuperadas através do GET também podem ser sensíveis.
Por outro lado, o uso de cabeçalhos personalizados considerou a implementação REST pura? Posso largar a autenticação básica e usar cabeçalhos personalizados. Dessa forma, pelo menos o ataque CSRF de um navegador pode ser evitado, e os aplicativos que usam o serviço definirão o nome de usuário / senha no heather personalizado. O que é ruim para essa abordagem é que agora o serviço não pode ser consumido a partir de um navegador.