Why Manual Validation Breaks Down

Objectives

By the end of this lesson, you should be able to:

• Identify the limitations of ad hoc if statement validation
• Explain what a mass-assignment vulnerability is
• Explain what a schema validation library adds beyond manual checks

💡 Why this matters: Every registration and login endpoint in this course so far checked required fields with a manual if (!req.body.email). That approach hasn’t broken yet because these examples were small, this lesson covers exactly where it stops holding up.

What Manual Validation Looks Like

if (!req.body.email || !req.body.password) {
  return res.status(400).json({ error: 'ValidationError', message: 'email and password are required' });
}

This works, for exactly two required fields, with no format checking at all. It says nothing about whether email actually looks like an email, whether password is long enough to be a reasonable password, or what happens the moment a third, fourth, and fifth field join the request body.

Where It Breaks Down

A real registration form has more than two fields, each with its own rule: email must be a valid email format, password needs a minimum length, age (if collected) needs to be a reasonable number, not a negative one or a string. Expressing all of that in nested if statements is possible, but it gets long, repetitive, and easy to get subtly wrong, forgetting one check, checking a type incorrectly, or writing an inconsistent error message compared to the field above it.

A More Serious Problem: Mass Assignment

app.post('/api/v1/auth/register', async (req, res) => {
  const user = { ...req.body, role: 'member' }; // "member" is the intended default
  // ...
});

If req.body is spread directly into a new object, and the request body happened to include { "email": "...", "password": "...", "role": "admin" }, the attacker-supplied role overwrites the intended default entirely, unless something explicitly strips fields that were never supposed to be user-settable. This is a mass-assignment vulnerability, real, and has caused real security incidents in production applications. Manual if checks for required fields don’t protect against this at all, they check that expected fields are present, not that unexpected ones are absent.

What a Schema Validation Library Adds

A schema (Lesson 2) declares exactly what shape data is allowed to have, field types, formats, minimum and maximum lengths, and, critically, which fields are allowed at all. Validating against a schema rejects malformed data consistently, with structured, predictable errors, and, as this module’s next lessons show concretely, strips fields that were never declared, closing the mass-assignment gap by default, not as an afterthought.

Try It

1. Write out, in words, every validation rule a real registration form (email, password, and a couple of other fields you choose) should actually enforce, and estimate how many if statements manually enforcing all of them would take.
2. Explain, in your own words, what a mass-assignment vulnerability is, using the role: 'admin' example above.
3. Look at a registration endpoint from an earlier module in this course, and identify one validation rule it never actually enforced (format, length, and so on).

Recap

• Manual if checks work for a couple of required fields, but don’t scale to real forms with format and length rules.
• Mass assignment, an attacker supplying unexpected fields like role: 'admin', is a real vulnerability manual required-field checks don’t address at all.
• A schema validation library solves both: consistent rule enforcement, and, by only accepting declared fields, closing the mass-assignment gap.

Next lesson: Zod, the schema validation library used for the rest of this module.