Defending against the OWASP Top Ten is critical so give an example of how you sanitize untrusted user input

Question

Anonymous · Accepted Answer

“Whenever I receive input from an untrusted source—such as an API request, query
parameter, HTTP header, or uploaded file—I treat it as untrusted by default. I
don't rely only on sanitization; I combine validation, canonicalization,
parameterization, and output encoding depending on where the data is being used.

For example, suppose we have an API that accepts a customer search:

GET /customers?name=<user-input>

A common mistake would be to concatenate that value into a SQL query:

SELECT * FROM customer WHERE name = ' + input + '

That creates a SQL injection vulnerability.

At the application layer, I would first validate the input against the expected
business format—for example, customer name may allow letters, spaces, hyphens
and a limited set of Unicode characters, with a maximum length. I would also
canonicalize the input where appropriate so that different representations of
the same input cannot bypass validation.

Then, most importantly, I would use a parameterized query:

SELECT * FROM customer WHERE name = ?

and pass the validated value as a parameter through JPA/Hibernate or JDBC
prepared statements.

If the same value is subsequently displayed in an HTML response, I would also
apply context-specific output encoding. For example, HTML encoding for HTML
context, JavaScript encoding for JavaScript context, etc. I would never assume
that because input was validated for the database, it is automatically safe for
the browser.

For something like an uploaded file, I would take additional measures: validate
file type and size, don't trust the client-provided MIME type, generate the
storage filename on the server, store it outside the web root or in object
storage, and scan the content where appropriate.

From an architectural perspective, I don't want every developer implementing
security independently. I would establish these controls as reusable components
and standards—for example, centralized request validation, secure coding
guidelines, parameterized data-access APIs, API gateway/WAF protections,
security headers, and automated SAST/DAST/dependency scanning in CI/CD.

I would also apply defense in depth. Validation is not the security boundary by
itself. The database should have least-privilege credentials, APIs should have
authentication and authorization, sensitive operations should be audited, and
monitoring should detect abnormal input patterns.

So my general principle is:

Validate what you expect → canonicalize where required → parameterize when
interacting with interpreters → encode for the output context → enforce
authorization and least privilege → monitor and test continuously.

That approach protects against several OWASP Top Ten risks, particularly
injection and XSS, rather than treating ‘sanitization’ as a single security
mechanism.”

Defending against the OWASP Top Ten is critical so give an example of how you sanitize untrusted user input

Practice this question with AI

Go Premium

Community Answers

Unlock Full Access

Practice More Questions