Use built-in middleware selectively

The public read API has a narrow CORS policy, while the internal health route does not inherit browser credentials. That contrast gives us something useful to test instead of a rule to memorize.

Built-in middleware saves code but still encodes policy that must match the route and deployment. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

The happy path can hide a bad design: you can mount every built-in globally to make the app feel production-ready and still get one successful demo. Push past the demo. read the middleware contract, mount it at the smallest scope, and verify headers and behavior with requests, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Compose routes and middleware so the request path stays short, typed, and visible. Save the before-and-after evidence now; it will make the final project review much more honest.

Create allowed and disallowed origin tests and inspect which routes receive each security or caching header. Save the evidence, then explain which requirement would force you to choose a different design.