Escena Viva already has routers, controllers and its own middleware. If you deployed it today it would work, and so would anyone who wanted to hurt it: it sends no security headers, it does not control which origin calls it, it does not log requests in a standard format, it compresses nothing and it does not stop a script from buying the catalog's 1,189 available tickets in a ten-second loop. In this lesson we assemble the minimum kit: five packages, one more mentioned, and for each one the same triad —what problem it solves, how it is configured and what happens if you leave it out—, all of them put through the Module 5 audit filter first.

1. The Module 5 criteria applied to each package
2. helmet: security headers
3. cors: requests from another origin
4. morgan: HTTP logging
5. compression: bandwidth
6. express-rate-limit: usage limits
7. cookie-parser: getting ready for Module 8
8. The correct order: the complete createApplication()

Before typing npm install, the check you already know how to run:

The result of the analysis for this lesson's packages:

That helmet and express-rate-limit have zero dependencies is exactly the kind of data point you were looking for in Module 5: less third-party code, less surface, less risk of a compromised maintainer ending up in your node_modules. And as always, watch out for typosquatting: the packages are called helmet (not helmetjs), cors (not express-cors) and express-rate-limit (not express-ratelimit). Install them with npm install helmet cors morgan compression express-rate-limit and check afterwards with npm ls --all --parseable | wc -l how much the tree has grown and with npm audit whether anything came with vulnerabilities.

What problem it solves. Browsers implement a dozen defense mechanisms that only kick in if the server asks for them with headers; without them they behave in the most permissive way possible. app.use(helmet()) is enough, and these are the headers that show up:

What happens if you leave it out: all those defenses stay off. None of them is essential on its own, nor does any replace validating the input, but together they turn several possible attacks into impossible ones for one line of code.

Here is the practical problem. helmet's default CSP includes script-src 'self', which blocks all inline JavaScript. If public/index.html has a <button onclick="buy('ses-001-1')"> or a <script> with venue constants, both will stop working and the browser console will show Refused to execute inline script because it violates the following Content-Security-Policy directive. The instinctive reaction is to disable the CSP. Do not: it is the only header on the list that really stops an XSS. The correct ways out, in order of preference: move the inline JavaScript into public/app.js and use addEventListener instead of onclick (an hour's work and it fixes the problem for good); if some inline script is unavoidable, use a per-response nonce; and only as a last resort relax the specific directive, never the whole CSP.

A pure API with no front end: if Escena Viva only served JSON, the CSP would be almost irrelevant and you could leave helmet() at its defaults. The conflict appears because we serve public/.

What problem it solves. The browser applies the same-origin policy: a page only reads responses from its own origin (scheme + host + port).

When they do not match, the browser makes the request but hides the response from the JavaScript unless the server authorizes it with Access-Control-Allow-Origin. Mind the nuance: CORS does not protect your server, it protects the browser user; a curl or a Node script ignores it entirely.

For "non-simple" requests —any POST with Content-Type: application/json, or with custom headers such as X-Request-Id— the browser sends an OPTIONS first, asking for permission:

And only if that response authorizes it does the browser send the real POST. Access-Control-Max-Age matters for performance: without it, the browser repeats the OPTIONS before every request.

The warning about credentials. If you enable credentials: true, the browser sends cookies and authentication headers on cross-origin requests, which opens the door for another site to act on behalf of a user with an open session. Three rules if you ever need it (Module 8): credentials: true requires a specific origin, because with '*' the browser rejects the response; never dynamically echo back the received Origin without checking it against the allowlist, because that is a fake allowlist that accepts everyone; and combine it with SameSite=Lax or Strict cookies and CSRF protection. What happens if you leave it out: the public/app.js served from another port will get the classic blocked by CORS policy and will not see a single response. If in production the front end is served from the same origin as the API, CORS is not needed: that is the safest scenario.

What problem it solves. It leaves a record of every request in a standard format that analysis tools know how to read. In 06-04 you wrote your own logger; morgan does the same with established formats and custom tokens.

In production logs are queried with tools that need one JSON object per line, not readable text; morgan allows it by defining tokens and passing your own stream:

With this, morgan replaces createRequestLogger from 06-04 (keep yours if you like it better: they do the same thing, and now you understand the third-party one from the inside). The skip option keeps the logs from filling up with the orchestrator's health probes. What happens if you leave it out: when something fails in production you will have no idea what the client asked for, or when, or how long it took. Debugging blind.

What problem it solves. JSON compresses extraordinarily well: the full Escena Viva catalog can go from 12 KB to under 2 KB, and fewer bytes means less load time and less transit cost.

Compressing what is already compressed burns CPU and sometimes increases the size. The default filter in compression already consults the MIME type table and avoids those cases.

In many deployments (Module 11) compression is done by Nginx or the CDN, not by Node. Compressing in Node works in any deployment with no external configuration and is essential if there is no proxy in front; compressing in the proxy frees CPU from the process and usually brings optimized brotli and a cache of compressed responses, but it requires control over that proxy.

A practical rule: enable it in Node by default; if later you measure that CPU is the bottleneck and there is a proxy in front, turn it off there, but never in both places at once. To check it, compare curl -s -H 'Accept-Encoding: gzip' -o /dev/null -w '%{size_download}\n' localhost:3000/api/events with the same call without the header. What happens if you leave it out: nothing breaks; you simply send three or four times more bytes than necessary in every response.

What problem it solves. Nothing stops a script from calling POST /api/orders in a loop: with 1,189 available tickets in the catalog and one request every 20 ms, the Auditorio Ribera runs out of capacity in under half a minute. It also protects against brute force on the Module 8 login.

When it is exceeded, the client gets a 429 Too Many Requests with RateLimit-Limit: 5, RateLimit-Remaining: 0, RateLimit-Reset: 43 and Retry-After: 43. RateLimit-Remaining tells it how many requests it has left and Retry-After how many seconds to wait; a well-built client respects them instead of retrying blindly.

Two limitations you must know about now. First: the default store is the process's memory, so with several processes (the Module 10 cluster) or several instances (Module 11) each one keeps its own count and the real limit is multiplied; the solution is a shared store in Redis (Module 10). Second: it depends on req.ip, which in turn depends on trust proxy; misconfigured, either all clients share the proxy's IP and block each other, or anyone forges theirs with a header. In Module 8 we will go deeper with per-authenticated-user limits, sliding windows and progressive delays. What happens if you leave it out: a single client can exhaust the capacity, saturate the process or try passwords without limit.

app.use(cookieParser(configuration.gatewayKey)) parses the Cookie header and leaves the cookies on req.cookies (and the signed ones on req.signedCookies). Escena Viva does not need it yet: the API is anonymous, there is no session and no endpoint depends on who you are.

We are flagging it because in Module 8 sessions with Passport and httpOnly, secure and SameSite cookies will show up, and then this middleware will be first on the list. Installing it now "just in case" would be adding surface for nothing: the Module 5 discipline also means not installing what you do not use.

This is the module's final code, commented line by line. The order is not arbitrary: every position has a reason.

The seven ordering rules, to memorize: identifier first (everything else references it); security early (so the headers reach errors and static files too); CORS before the limits (the preflight OPTIONS must not consume quota); limits before the body (do not spend CPU parsing what you are going to reject); body before the routes (req.body does not exist otherwise); 404 after the routes (it only catches what went unhandled); and errors last (it only sees what was registered before it). And the logging and rateLimiting flags are not a whim: in Module 9 you will set them to false so the tests do not fill the output with logs or fail when they hit the limit on request number 301.

• Disabling the whole CSP because it breaks the front end. That is throwing away the only real defense against XSS. Move the inline JavaScript into a file or use nonces.
• origin: '*' with credentials: true. The browser rejects the combination. And if you "fix it" by echoing back the received Origin without checking it, you have built an allowlist that accepts everybody.
• Believing that CORS protects the server. It protects the browser user; real authorization arrives in Module 8.
• Putting the limiter after express.json() (you parse 100 KB before rejecting) or using it with in-memory state and several processes (with four workers the real limit is quadruple; Redis in Module 10).
• Compressing images or video, or compressing in Node and in the proxy at the same time. You burn CPU to gain no bytes: leave the default filter and pick a single place.
• Installing cookie-parser without using cookies. Free surface: install it when you need it.
• morgan('dev') in production. The color codes are escape sequences that dirty the log files; use combined or your JSON formatter.
• Tip: add npm audit --audit-level=high to the check script. Every one of these packages is third-party code that runs on every request.

For the five packages in this lesson, build a table with: current version, license, date of the last publish, number of direct dependencies and whether it shows up in npm audit. Decide with reasons whether you would accept each one in a real project and what alternative you would look for if any of them had gone two years without a publish.

Configure cors so that it accepts http://localhost:5173 and https://escenaviva.test and rejects the rest. Prove the three cases with curl: the OPTIONS preflight request from an allowed origin (it must return the Access-Control-Allow-* headers), a GET from a disallowed origin (it must not carry Access-Control-Allow-Origin) and a GET with no Origin header (it must work normally).

Apply purchaseLimit to POST /api/orders with 5 requests per minute. Write a script that fires 8 back-to-back orders of 1 ticket for ses-001-1 and prints the status and the RateLimit-* headers of each one. Check that the last three return 429 with Retry-After and that the body respects the { error: { code, message, status } } format.

Solution 1

The criteria you should have applied: a permissive license, a publish in the last 12-18 months, few direct dependencies and recognizable maintainers. If cors had gone two years without a publish, the reasonable answer is not to abandon it —it is a small, stable package— but to keep an eye on its open issues and be ready to replace it with twenty lines of your own middleware, because CORS is ultimately four headers.

Solution 2

The third case proves the key point: CORS is a browser defense, not a server one.

Solution 3

Expected output: attempts 1 to 5 return 201 with RateLimit-Remaining dropping from 4 to 0; attempts 6, 7 and 8 return 429 with Retry-After: 52. Without the limiter, all eight would have sold a ticket; with ses-001-1's capacity, an unchecked loop exhausts it in seconds.

Escena Viva now ships with the minimum kit of a production API. helmet adds a dozen security headers for one line, with the important caveat that its CSP forces you to move the inline JavaScript out of the front end —and that is the correct solution, not disabling it. cors authorizes public/app.js to call the API from another origin via an allowlist read from the configuration, never with '*', and you now know what a preflight request is and why credentials deserves respect. morgan logs every request in a standard format and, with custom tokens, as one JSON object per line ready for Module 11. compression trims the size of responses when it pays off. And express-rate-limit stops a script from exhausting the capacity, with the warning that its in-memory store does not survive several processes.

Above all, you have seen the complete version of createApplication() with the seven ordering rules reasoned out: identifier first, security early, CORS before the limits, limits before the body, body before the routes, 404 after the routes and errors last. But one very large hole remains: POST /api/orders still does recordOrder(req.body) with whatever comes in the body —a quantity of -5, a sessionId that is an object, a 40,000-character e-mail address— and no middleware in this lesson looks at the content of the data.

In the next lesson, Input Data Validation, we close that hole: why you never trust the client even if the form validates, where validation must live (at the edge, not in the domain), the zod schemas for Escena Viva's orders, a generic validate(schema, source) middleware that leaves the result on req.validatedData —and that respects req.query being read-only—, and how to return a 400 that genuinely helps the caller without revealing what it should not.