POST /api/orders still does recordOrder(req.body) with whatever arrives. Helmet, CORS and the rate limiter do not look at the content: a body with quantity: -5, a sessionId that is an array or a 40,000-character e-mail address sails through all of them without breaking a sweat. This is the hole we close now. Validation is one of the things Express does not do for you (we said so in 06-01, table included) and it is also one of the ones with the biggest consequences when it is missing. In this lesson we decide where it lives, pick a tool, write Escena Viva's schemas and build a generic middleware that sits on the route and hands over data already clean and converted.

1. Why you never trust the client
2. What gets validated and where validation must live
3. Validation by hand and why it becomes unmaintainable
4. zod: the validator of choice
5. Escena Viva's schemas
6. The generic validate(schema, source) middleware
7. Coercion and normalization
8. The useful error response
9. Less obvious uses: responses and configuration
10. Sanitization versus validation

public/app.js validates the form before sending: it checks that the quantity is between 1 and 6, that the e-mail address has an at sign and that a session is selected. And even so, the server must validate everything again. The reasons, from the most obvious to the least:

1. The client is not your form. Anyone can call the API with curl, with Postman or with a script: your HTML is a suggestion, not a control.
2. The client can be modified. The browser developer tools let you change an input's max in two seconds.
3. There may be more clients. A mobile app, a box-office dashboard, an integration with a promoter. Each one with its own bugs.
4. Intermediaries alter data. Proxies, redirects, retries with a truncated body.
5. The client validates for experience; the server validates for integrity. The first avoids frustration, the second avoids corruption.

The classic formulation: client-side validation is courtesy; server-side validation is obligation. And it is not only about attackers: a front-end deployment that sends quantity as a string instead of a number because of a typing bug causes exactly the same wreckage, with no bad intent.

And the most important question: where do you put that validation? The journey is Client → validate() → Controller → Service → Domain, and there are two very different rejection points: the validate() middleware returns 400 when the shape is invalid, and the domain returns 409 when there is not enough capacity. They are two levels with different responsibilities, and confusing them is a frequent design mistake:

The rule: the edge guarantees the shape; the domain guarantees the rules. Session.sell() must not check whether quantity is a number —that is already guaranteed by the time it gets there— but it must check whether there is capacity, because that depends on state and can change between the validation and the sale. And the other way around: if you delete the validation middleware, the domain must not break catastrophically, but it is not its job either to produce friendly messages for an HTTP client.

Remember how order-routes.js ended up in Module 4:

Five concrete problems, and all of them get worse over time:

1. It stops at the first error. The client fixes sessionId, resends, and discovers that quantity was wrong too: three round trips for three errors.
2. It does not return the converted result. You validate data.quantity but you keep using the original, unnormalized object.
3. Extra fields get through. If the client sends { quantity: 2, isAdministrator: true }, that field reaches the domain untouched.
4. It is impossible to reuse. The same order validated from a message queue or an import script needs copy and paste.
5. It cannot be documented automatically. There is no description of the expected shape; only imperative code you have to read in full.

Fifty lines for four fields: with twenty endpoints, this is half the project.

zod flips the approach: instead of writing checks, you describe the shape of the data, and the library derives validation, conversion and messages from it. It is installed with npm install zod, and npm view zod license dependencies confirms what you were looking for in Module 5: MIT and zero dependencies.

A short and honest comparison:

We choose zod for three reasons that fit the course: zero dependencies (the Module 5 criterion), independence from Express (the same schema serves the API, an import script and the Module 9 tests) and because the schema is a single source of truth that documents the input better than any comment. The essentials of its API: you declare an object with z.object({ name: z.string().min(1).max(80), age: z.number().int().positive(), email: z.email(), channel: z.enum([...]), notes: z.string().optional(), active: z.boolean().default(true) }) and you run it with schema.safeParse(data) —which returns { success, data } or { success, error }— or with schema.parse(data), which returns the data or throws a ZodError.

A key detail: z.object() discards undeclared keys by default. { quantity: 2, isAdministrator: true } comes out of the validator as { quantity: 2 }, so problem 3 from the previous section is solved out of the box. And if you prefer to reject rather than discard, .strict() makes the extra key an error.

Compare it with the fifty imperative lines from section 3: there are more rules here, in less space, and they read like a specification. And MAX_TICKETS_PER_ORDER is still the same constant from Module 4: the rule has not changed, only the place where it is expressed.

A single configurable middleware that goes on any route. It is a factory, like the ones in 06-04.

Usage in the routes, and a controller with no checks left:

In Express 4 the usual pattern was req.query = result.data, and it worked. In Express 5 req.query is a getter with no setter, and that line throws TypeError: Cannot set property query of #<IncomingMessage> which has only a getter; if you migrate old code, it is one of the first errors you will see. Storing on req.validatedData is not just a way of dodging the limitation: it is better design, because it makes it explicit in the controller that the data it uses has been through a schema, and it keeps what came from the client intact in case the logger needs to compare it.

Everything that arrives over HTTP is text. req.params and req.query are always strings —in GET /api/events?page=2, req.query.page is '2', not 2—; only req.body with Content-Type: application/json preserves types, and only if the client sent them properly. That is why converting is part of validating, not a later step:

Without lowercasing the e-mail address, [email protected] and [email protected] are two different buyers: duplicates in master data almost always come from a normalization that was missing.

Careful with excessive coercion. z.coerce.number() accepts '' as 0 and true as 1, because it uses Number() underneath. If that does not suit you, be explicit: z.string().regex(/^\d+$/).transform(Number). Friendly coercion in the query (where everything is necessarily text), strict coercion in the JSON body (where the client could have sent the right type).

We keep the format set in Module 4 and add details to it:

What makes this response useful: it gives all the errors at once (one round trip instead of three), the exact field with a full path in nested structures (tickets.0.quantity), a readable reason written by you in the schema, a stable type (too_big, invalid_type) that a client can handle programmatically without depending on the language, and the request identifier from 06-04 so it can be cross-referenced with the server logs.

And what must never show up:

Both are legitimate and the debate is open. Our policy, consistent with the STATUS_BY_CODE table from Module 4:

What matters is not which one you choose, but that it is consistent across the whole API and documented.

Schemas are not only for what comes in.

In 06-02 you wrote functions by hand (required, integer, list); a schema does the same in less space and with better messages:

The same "fail fast" principle, with a single place describing everything the application needs in order to start.

src/services/currency-exchange.js does a fetch against an API you do not control: the fact that it returns { rates: { USD: 1.08 } } today does not guarantee that tomorrow it will not return { data: [...] } after a version change.

The cost is minimal and it avoids the worst kind of failure: the one that does not blow up where it happens, but three layers down with an incomprehensible undefined.

They get confused constantly, but they are different things:

The rule that prevents most mistakes: validate on the way in, escape on the way out. Why not escape when storing? Because escaping depends on the destination and by storing escaped data you lose the original: if you store <script> and send it as JSON to a mobile app, that app literally shows <script>; if the same comment goes to an HTML page, to a CSV and to an e-mail, each destination needs a different escaping; and if you change templating systems, your data is already contaminated with the previous one's escaping.

Store the data as it is (validated, normalized) and escape at the rendering point. In Escena Viva, the public/app.js that renders comments must use textContent instead of innerHTML: that is the correct escaping for that destination.

You will see it repeated that "validation prevents SQL injection". That is false as a primary defense: a denylist of words (DROP, --, ;) can be dodged in a thousand ways and rejects legitimate comments from buyers called O'Brien. The real protection is parameterized queries, which separate code from data so the engine never interprets a value as an instruction; that arrives in Module 7, with Mongoose and Sequelize.

Meanwhile, in Escena Viva persistence is a JSON file and the equivalent risk is different but real:

• Path traversal if an identifier ends up being part of a file path. That is why resolveWithin is still mandatory (Module 3).
• Prototype pollution if you do Object.assign({}, req.body) with a __proto__ key. zod protects you because z.object() discards what is undeclared.
• Denial of service with enormous bodies or catastrophic regexes. That is why limit is there in express.json() and patterns are bounded in the schemas.

Validating reduces surface, but it does not replace the specific defense of each destination.

• Trusting the form's validation or reassigning req.query/req.params (a TypeError in Express 5): the HTML is courtesy, the server is the real border, and the result goes to req.validatedData.
• Validating inside the domain. Session.sell() must not check types: by the time it gets there they are already correct. Its job is capacity.
• Returning only the first error (it forces the client into one round trip per field; safeParse gives them all) or failing to filter the internal error: never send stack traces or received values, log them on the server and return just what is needed.
• Indiscriminate coercion (z.coerce.number() turns '' into 0 and true into 1) or forgetting .trim() (a ' ses-001-1 ' fails against the regex with a baffling message).
• Duplicating schemas across routes. Extract the common fragments (sessionId, buyerEmail) and compose them.
• Tip: the schema is executable documentation. When someone asks what POST /api/orders accepts, the answer is src/schemas/order.js, and it cannot be out of date because it is the code that runs.

Escena Viva wants to allow orders with tickets for several sessions at once. Write createMultiOrderSchema with email, channel and tickets, an array of 1 to 4 items with sessionId and quantity. Add two rules that a per-field schema cannot express: the total number of tickets cannot exceed 6, and the same sessionId cannot be repeated. Hint: .superRefine() on the whole object.

Apply validate(eventsQuerySchema, 'query') to GET /api/events and adapt the controller to read from req.validatedData.query. Check with curl that ?perPage=999 and ?page=abc return 400 with the field and the reason, that ?soldOut=true arrives as a boolean and that with no query the defaults are page: 1, perPage: 10.

Send POST /api/orders a body with an undeclared field, for example {"sessionId":"ses-002-1","quantity":2,"email":"[email protected]","priceCents":1}. Check that the order is created and that priceCents does not reach the service. Then modify the schema with .strict() and check that it now returns 400 pointing at the extra key. Reason about which cases you would prefer each behavior for.

Solution 1

superRefine is the place for rules that cross fields. Careful: they are still shape rules, not state rules. "Is there capacity for these 6 tickets?" still belongs to the domain, because it depends on sales at that moment.

Solution 2

Compare the controller with the version from the 06-03 exercise: the parseInt calls, the ?? and the manual caps are gone. That logic has not been lost, it has moved into the schema.

Solution 3

When to prefer each one: pruning (the default behavior) fits a public API with varied clients, because an old client that sends obsolete fields keeps working; .strict() fits an internal API or one with sensitive fields, because an unexpected field is usually a client bug and it is better to flag it early. The crucial part in both cases: priceCents must never come out of the client's body; the price is set by the server by reading the session. If a body field can alter the money, you have a much bigger problem than a misconfigured schema.

Validation is your application's border, and Escena Viva now has it properly placed. You know why the browser form does not count, what gets validated (body, params, query, headers) and —conceptually the most important part— where each thing lives: the edge guarantees the shape, the domain guarantees the rules that depend on state; the first returns 400, the second 409. You have swapped Module 4's fifty imperative lines for declarative zod schemas that are validation, conversion, normalization, pruning of extra fields and executable documentation all at once. The validate(schema, source) middleware goes on any route, leaves the result on req.validatedData respecting that req.query is read-only in Express 5, and frees the controllers from every check. And you have seen the less obvious uses —validating the startup configuration and external services' responses— plus the distinction between validating on the way in and escaping on the way out, with the honest warning that the real defense against injection is the parameterized queries of Module 7.

One detail remains unresolved, and it is the one that closes the module: the validate middleware does not respond, it calls next(new ValidationError(...)), and that ValidationError does not exist yet and nobody is picking it up. The same goes for the EVENT_NOT_FOUND that loadEvent propagates, the INSUFFICIENT_CAPACITY the domain throws, the malformed JSON that express.json() rejects and the 404 for nonexistent routes.

In the next lesson, Error Handling, we build the destination for all of them: the four-argument error middleware, a hierarchy of our own in src/errors.js, the definitive home of the STATUS_BY_CODE table you wrote in Module 4, the distinction between operational errors and programming errors, and the policy for what to do when something fails beyond Express's reach.