Inputs are everywhere, often only evident in hindsight. User input and file uploads are just the tip of the iceberg, but what if we consider more than input and instead the code itself? Here are a couple of examples to illustrate this point.
Do you trust all of your dependencies? How about all of the transitive dependencies of your application? It is not uncommon to for an application to have a page that lists its dependencies versions and licenses (the later might even be required depending on the license). The popular Node package manager (npm) has had a few projects which have contained maliciously formed license fields. In another npm incident, packages ran malicious scripts upon installation automatically that uploaded the user's environment variables to a third party.
Every dependency is code you include from other systems across your trust boundary. Properly inspecting and validating your dependencies is a critical first step of any input sanitation plan. GitHub recently introduced automated security alerting to let you know when your dependencies might have security issues. Pay attention to these and you can prevent a lot of headaches.
Almost all values from an HTTP request can be changed by the sender and need to be handled accordingly. To help illustrate this, here is a simple HTTP POST including numerous headers to
POST /submit-me HTTP/1.1 Host: example.com Accept: */* Referer: http://example.com/fake.html Accept-Language: en-us Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate User-Agent: My Fake UserAgent <img src onerror='alert("haxor")'> Content-Length: 37 Connection: Keep-Alive Cache-Control: no-cache foo=bar&key=value
You can see right away: request headers are user input too. Imagine for a moment that an HTTP client maliciously changes the User-Agent header. The logged User-Agent may falsely identify a request as coming from a different client application than the one in which it really originated.originated from. While that's unlikely to affect the current request, it might cause confusion in the application's logging and reporting system.
As these examples illustrate, even sanitizing relatively innocuous inputs is an important part of an overall security strategy.