You can separate configuration from application code, explain server extension points, and harden a small deployment using least privilege and safe defaults. Readiness: identify where a request becomes application logic in Lecture 02.
A team enables directory listing, runs the application as an administrator, logs session cookies, and exposes a debug endpoint. The code may be correct, yet the deployment leaks data. Security includes configuration, identity, transport, input/output handling, dependencies, and monitoring.
Servers can be extended through modules, reverse-proxy handlers, authentication providers, filters, or application runtimes. Keep environment-specific values – ports, upstream addresses, certificate paths, log levels – outside source code. Validate configuration at startup and fail closed when a security-critical value is missing.
flowchart LR
C[Client] --> T[TLS + virtual host]
T --> F[Security filters]
F --> R[Router]
R --> S[Static files]
R --> A[Application upstream]
A --> D[(Database)]Text equivalent: transport and host selection happen first, security filters inspect the request, routing selects static or application handling, and the application accesses data with a restricted identity.
Unsafe: an upload directory executes scripts and is served directly. Repair: store outside the executable web root, generate server-side names, allow-list type/size, scan if required, and serve through a handler that sets a safe content type and Content-Disposition. Authorization must be checked when retrieving, not only when uploading.
Configuration exposes verbose stack traces to all users. Hint 1: which audience needs diagnostic detail? Hint 2: separate public response from internal log. Solution: return a generic error and correlation ID; log controlled details with secrets removed; restrict debug mode to a protected development environment.
Create a deployment checklist for one static directory and one Java upstream: listener, host, TLS, document root, proxy route, upload rule, log redaction, process identity, error page, and backup. Review a sample config for duplicate routes and accidental public files. No production change is required.
Q1: Module versus reverse proxy? Answer: a module executes inside the server process; a reverse proxy forwards to a separate upstream process.Q2: Why validate config at startup? Answer: to detect unsafe or unusable state before serving requests.Q3: Best response to an unexpected exception? Answer: generic client error plus a traceable, sanitized server log.Threat-model a student file-submission route. List assets, actors, trust boundaries, five threats, and one prevention/detection control per threat. Rubric: model 3, plausible threats 3, matched controls 3, residual risk 1.
Harden layers: network/TLS, server, application, data, operations. Least privilege limits damage; defense in depth assumes one control can fail.