We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Core Fundamentals
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Core Fundamentals
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
There's a famous XKCD comic. A school calls a mother: "Did you really name your son Robert'); DROP TABLE Students;--?" The mother replies: "Oh yes. Little Bobby Tables, we call him."
It's funny because it's real. injection, sending malicious input that gets executed as code, has been the number one web vulnerability for over two decades. The OWASP Top 10 has listed injection attacks in the top spot since the list's creation in 2003.
In 2017, Equifax lost the personal data of 147 million Americans. The breach was traced to an unpatched vulnerability, but the damage was amplified by insufficient input validation throughout their systems. In 2011, Sony's PlayStation Network was breached via SQL injection, exposing 77 million accounts. In 2023, a SQL injection vulnerability was found in MOVEit Transfer, affecting over 2,000 organizations and 60 million people.
All of these attacks share the same root cause: the system trusted user input.
Injection has been near the top of the OWASP list for over twenty years, though the story is more interesting than "it never moved".
Never trust user input. Not from forms. Not from APIs. Not from your own mobile app. Not from your "trusted" partner's system. Not from your own frontend. Input validation is the first and most important line of defense in any application. Every byte that enters your system from the outside world is guilty until proven innocent.
Input validation is the process of checking that incoming data meets your expectations before you do anything with it. Before you store it, before you query with it, before you display it, before you pass it to another service.
There are two flavors:
Is it the correct data type? Is the string the right length? Does the email match an email pattern? Is the number within an acceptable range?
Input: "age" = "twenty-five"
Expected: integer
Result: REJECT, wrong type
Input: "email" = "not-an-email"
Expected: valid email format
Result: REJECT, invalid format
Input: "quantity" = -5
Expected: positive integer
Result: REJECT, out of range
Even if the data is syntactically correct, does it make logical sense in context?
Input: "birthDate" = "2025-01-01" (for an adult account)
Syntactically: valid date format ✓
Semantically: person would be 1 year old ✗
Input: "startDate" = "2025-06-01", "endDate" = "2025-05-01"
Syntactically: both valid dates ✓
Semantically: end date before start date ✗
Input: "countryCode" = "XX"
Syntactically: 2-letter string ✓
Semantically: not a real country ✗
Most validation failures in production are semantic, not syntactic. The data looks right but isn't. A properly typed, correctly formatted, completely wrong value slips through and corrupts your database or causes a downstream failure hours later.