Prerequisites — stop here if you have not completed them. This lesson assumes vocabulary and concepts introduced inhttp-fundamentals,browser-security-model,clickjacking-ui-redressing, andautomated-scanning-triage. If any of those are incomplete, finish them first and return here — the header mechanics below will not land without that foundation.
Many of the lessons leading to this one focus on attacking — finding a flaw and proving it is exploitable. This lesson takes the defender's side: instead of looking for a weakness to use, you will look for a weakness to close. Security response headers are short, declarative instructions a server attaches to every HTTP response, switching on defenses the browser already ships with: refuse to be framed, restrict where scripts may load from, never downgrade to plaintext HTTP, stop guessing content types.
Missing or misconfigured security headers are a deployment-time defect — the code may be correct but the server's response was not hardened. This lesson addresses the header-specific subset of A05:2021 — Security Misconfiguration in the OWASP Top 10, the same category as the exposed-files and default-credentials findings in Lesson 1.
They cost almost nothing to set and are the highest-leverage hardening a defender can apply - yet applications routinely ship without them. That is exactly why a passive scan of NovaCart hands you a cluster of "header not set" alerts for free. This lesson is where those alerts finally get fixed.
This is the header-hardening companion to the code-level fixes in input-validation-output-encoding.
The headers that matter most — grouped by what they protect:
Transport security (keep the connection encrypted):
- **
Strict-Transport-Security** (HSTS) — forces HTTPS only and defeats downgrade and SSL-stripping attacks (an attack where a network-level attacker intercepts an HTTP redirect and silently keeps the connection in plaintext).
Browser behavior controls (restrict what the browser is allowed to load and display):
- **
Content-Security-Policy** (CSP) — an allowlist for where scripts and resources may load from; the strongest in-browser mitigation for XSS. - **
X-Frame-Options** / CSPframe-ancestors— blocks the framing that makes clickjacking possible. - **
X-Content-Type-Options: nosniff** — stops the browser guessing (MIME-sniffing) the content type of a response. - **
Referrer-Policy** — limits how much of the current URL leaks to other sites via theRefererheader.
Session cookie protection (flags added to the Set-Cookie header):
- Cookie flags (
Secure,HttpOnly,SameSite) — protect the session cookie from interception, theft by injected scripts, and cross-site misuse.
In this lesson you will:
- Read the simulated NovaCart response headers in Header Scan and judge which are present, weak, or missing.
- Name one missing or weak security header.
- Recognize what HSTS actually does, and recommend a hardened baseline a developer could apply.
The throughline: a header mitigates a vulnerability; it does not remove it. Set the header and fix the flaw in the code — headers are the outer layer of defense-in-depth (multiple independent protective layers, so that a failure at one does not become an incident), never a substitute for it.
Estimated time: eight to twelve minutes.
When you are ready, send the Continue signal.