Errors, security, and observation
Configure proxies, CORS, and headers
Set trust proxy and cross-origin policy from the real deployment path instead of copying permissive snippets.
9 minute lesson
The app trusts only its known proxy hop and allows one documented frontend origin with the required methods and headers. That contrast gives us something useful to test instead of a rule to memorize.
Proxy trust affects client IP and secure-cookie behavior; CORS controls which browser origins may read responses, not who can call the server. 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 enable trust proxy blindly and use wildcard CORS with credentials and still get one successful demo. Push past the demo. model the proxy chain, allow only required origins and methods, and add defensive response headers at the app or edge, then test the condition most likely to prove the choice wrong.
The module is moving toward one outcome: Make failures safe for users and useful for operators without leaking secrets or losing requests silently. Save the before-and-after evidence now; it will make the final project review much more honest.
Test direct and proxied requests plus allowed and disallowed browser origins; inspect derived IP, protocol, and CORS headers. Save the evidence, then explain which requirement would force you to choose a different design.
Lesson completed