Chapter 1 of 6 · 4 practices · 5 min · 4-question quiz
Treat all input as untrusted
Where input comes from, how to validate it at the boundary, and the canonicalization and size limits that have to happen before any check means anything.
Start: Know every place untrusted data enters your code4 practices in this chapter
- 1Know every place untrusted data enters your codeYou cannot validate input you did not notice. Most teams think of form fields and JSON bodies, but attackers control far more than that. Treat all of these as untrusted: A trust boundary is any line…
- 2Validate every input against an allowlist schema at the boundaryOWASP describes two layers of validation: Syntactic: the value has the right type and shape (an integer, a UUID, an ISO date, a string of at most 200 characters); Semantic: the value makes sense here…
- 3Canonicalize input once, before you validate itA check only works on the form of the data that will actually be used. If you validate one representation and use another, an attacker picks the gap. Common examples: URL encoding:
%2e%2e%2fis… - 4Limit size and complexity before you parseA schema check runs after parsing. If the parser itself can be exhausted, the schema never gets a chance. OWASP puts it this way: "A schema check after parsing cannot protect a parser that has…
Check yourself on this chapter
4 questions, right here once you are signed in. Your progress is saved as you read.