Insufficient input and output validation is one of the OWASP Mobile Top 10 risks, and it underlies a long list of more specific bugs: SQL injection, command injection, cross-site scripting in a WebView, and crashes from malformed data all trace back to trusting input that should have been validated. The principle is simple, treat data crossing into your app from anywhere as untrusted, validate it before you use it, and encode it safely on the way out, but the surfaces are many. Here is what M4 covers, where it shows up in mobile apps, and how to validate properly.
Short answer
Insufficient input/output validation, OWASP Mobile Top 10 category M4, is failing to validate and sanitize data that enters your app from external sources, or to safely encode data on output, which leads to injection attacks, corruption, and crashes. Per OWASP, the inputs to treat as untrusted include network responses, user input, inter-app communication, deep links, and files, and the defense is to validate input against what you expect before using it, parameterize anything that goes into a query, and encode output appropriately, such as for a WebView. Both the client and the server must validate, since neither can trust the other's data. Treat all data crossing a trust boundary as untrusted input.
What you should know
- M4 is about trusting input: failing to validate data from external sources.
- It causes injection and crashes: SQL, command, WebView script, malformed data.
- Many inputs are untrusted: network, user, IPC, deep links, files.
- Validate input, encode output: check what comes in, encode what goes out.
- Both client and server validate: neither trusts the other's data.
What is insufficient input/output validation?
It is using data without first confirming it is safe and well-formed. Every app takes in data, from the network, from the user, from other apps, from deep links, from files, and produces output that is displayed or passed to another component. The vulnerability arises when that data is used without validation: an unvalidated value concatenated into a database query becomes SQL injection, passed to a command becomes command injection, rendered into a WebView becomes cross-site scripting, and malformed data can crash the app or corrupt state. The output side matters too: data that is not safely encoded for its destination, HTML for a WebView, for example, can be interpreted as code. M4 is the general category behind these specific flaws, and the unifying mistake is treating data that came from outside your trust boundary as if it were trustworthy.
Where does it show up in mobile apps?
Anywhere external data enters or leaves your app. The table lists the common surfaces.
| Surface | Risk without validation |
|---|---|
| Network responses | Malformed or malicious data drives a bug |
| User input | Injection or invalid state from crafted input |
| Deep links and URLs | Crafted parameters reach sensitive logic |
| Inter-app communication | Data from another app, including a malicious one |
| Output to a WebView | Unencoded data interpreted as script |
The pattern is that each of these is a trust boundary: data crossing it is controllable by someone other than you, so it must be validated on the way in and encoded on the way out. A value from your own UI is not automatically safe either, since an attacker can bypass the UI and send crafted input to your API directly, which is why validation has to happen where the data is used, not only where it is entered.
How do you validate properly?
Validate against expectations, parameterize, and encode for the destination. Validate input by checking it against what you actually expect, type, format, length, range, allowed values, and reject or sanitize anything that does not fit, rather than trying to filter out known-bad patterns. For data that goes into a query, use parameterized statements rather than building the query by concatenation, which closes injection. For data rendered into a WebView or other interpreter, encode it appropriately so it is treated as data, not code. Validate on both the client and the server, since the client improves the user experience but the server is the authority and must not trust what the client sends. And handle malformed input gracefully so it does not crash or corrupt state. The principle is to never use external data as-is: confirm it is what you expect before acting on it, and encode it safely when it leaves.
What to watch out for
The first trap is trusting input because it came from your own UI, when an attacker can send crafted input to your API directly; validate where the data is used. The second is building queries or commands by concatenating input, which is injection; parameterize instead. The third is rendering unencoded data into a WebView, which can become script. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled binary against OWASP MASVS and assesses how your app handles input and data, including WebView and query handling, which helps you find unvalidated paths before you ship. Server-side validation is work you do on your backend.
What to take away
- Insufficient input/output validation (M4) is failing to validate external data or safely encode output, which leads to injection, corruption, and crashes.
- Treat network responses, user input, inter-app communication, deep links, and files as untrusted, and validate where the data is used.
- Validate input against what you expect, parameterize queries, encode output for its destination, and validate on both client and server.
- Use a pre-submission scan such as PTKD.com to assess how your app handles input and data and find unvalidated paths before you ship.
