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 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.