Is it over-engineering if I add protection against a user's intentional wrongdoing (to put it mildly), if the harm the user can incur is not related to my code?
To clarify, I'm exposing a simple JSON RESTful service like this:
GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item
The service itself is not meant to be used trough a browser, but only from third party applications, controlled by the user (like phone apps, desktop app, etc.). Also, the service itself should be stateless (i.e. session-less).
The authentication is done with Basic Authentication over SSL.
I'm talking about one possible "harmful" behavior like this:
The user enters the GET url in a browser (no reason but...). The browser asks for Basic Auth, process it, and stores the auth for the current browsing session. Without closing the browser, the user visits malicious web site, which has a malicious CSRF/XSRF javascript which makes a POST to our service.
The above scenario is highly unlikely, and I know that from a business perspective I should not worry too much. But for the sake of improving the situation, do you think that if the username/password are required in the JSON POST data as well, will help?
Or should I drop Basic Auth altogether, get rid of the GET, and use only POST/PUT with authorization information in them? As the information retrieved trough GET can be also sensitive.
On the other side, does using custom headers considered pure REST implementation? I can drop the Basic Auth, and use custom headers. That way, at least CSRF attack from a browser can be avoided, and the applications which use the service will set the username/password in custom heather. Bad for this approach is, that now the service can not be consumed from a browser.