Input validation is often required to safe guard against inappropriate use. For example, consider the following API:
1 2 3 4 5 6 7 8 9 10 11 12 13
In this case, the API is expecting a
from_account_id which we know, can be easily exploited unless a validation is performed on the server. Say, a simple validation would do this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
This is an absolutely necessary validation to be performed on the server.
However, the validation requirements can be a little relaxed at times. For example, if you know the only client of your API is also your own app, then you may not need to handle all possible validations both in the server and cliend side and come up with fancy errors. When its non-destructive, an invalid request can just be shown the general purpose error page, since this is only for bad users trying to hack the API calls.
For example, lets say we have the following code:
1 2 3 4 5 6 7 8 9
Say, by business logic, everyone can see the apointments for any user. Now, the above code will surely fail if any of
user_id/date is not provided, or has a bad data. So, its possible to add the validation logic. But if I know I’m writing the only client that’s supposed to hit this API using a client side validated request, I’d just skip the input validation. This is not destructive anyway.
I think it’s a trade-off between paranoid programming and pragmatic design. As long as I’m providing expected behavior in the app without opening up a security hole, some validations may be skipped on purpose.