It's not unusual for web application developers to write UIs that impose some restrictions on the user, but don't employ those same restrictions in the APIs to which those UIs send data. The APIs are written with the assumption the UI has prevented the user from sending invalid input. What happens when those APIs are used with a different UI or no UI at all?
A UI lets the user enter an email address. The UI disallows the user from entering some valid email addresses that contain certain specific punctuation characters because the developers decided that those characters are invalid. Maybe the developer had a good reason for this restriction or maybe it's a mistaken interpretation of email address specifications.
- The user may become frustrated and chooses not to use this application.
- The users settles for using some other email address that the UI allows.
The user decides to try working around this flaw in the system:
- The user temporarily accepts the UI's restriction, using an email address it deems valid.
- The user enables debugging tools in the web browser and starts logging the requests sent between it and the API on the server.
- The user submits the email address, which is sent to the API in a request.
- The user finds this request in the log and copies all the data about the request, including the request URL, method, headers, cookies, form data, etc.
- The user finds the email address they settled for in the request data, changes it to the email address they actually wanted, and sends the request again using a tool like CuRL or wget.
- The API accepts the request and uses the email address the user wanted, but that the UI wouldn't allow.
- Everything could work out fine.
- The new, "invalid" email address may cause other problems in the system.