Which HTTP response headers improve security?

Security response headers are cheap, high-leverage controls: the server tells the browser to enforce safer behavior, with no application logic changes. Each one closes a specific gap.

The headers that matter

• Strict-Transport-Security (HSTS). max-age=63072000; includeSubDomains tells the browser to only ever connect over HTTPS to this host, even if the user types http:// or clicks an HTTP link. This defeats SSL-stripping man-in-the-middle attacks that downgrade the connection. The browser preload list bakes this in before the first visit — powerful, but hard to undo, so get the config right.
• Content-Security-Policy. Constrains where scripts and other resources load from; the strongest header-based XSS mitigation (covered in depth on its own).
• X-Frame-Options / CSP frame-ancestors. Controls who may embed your page in an <iframe>, defeating clickjacking (overlaying your UI under a decoy). frame-ancestors is the modern, more flexible replacement.
• X-Content-Type-Options: nosniff. Stops the browser from MIME-sniffing a response into a different content type. Without it, a file you serve as text could be interpreted as executable script — turning a benign upload into stored XSS.
• Referrer-Policy. Limits how much of the URL is sent in the Referer header to other sites, preventing leakage of sensitive tokens or internal paths.
• Permissions-Policy. Disables powerful browser features (camera, geolocation) the app does not need, shrinking attack surface.

What to remove

Just as important: strip information-disclosure headers like Server and X-Powered-By that hand attackers your exact stack and version.

Why headers are defense in depth

They do not fix vulnerable code; they reduce exploitability and blast radius across the whole site at once.

Interviewers look for you naming several headers and, crucially, the specific attack each prevents — HSTS/SSL-strip, X-Frame-Options/clickjacking, nosniff/MIME-sniffing — rather than just listing names.