Security Headers Audit Lab

HTTP Security Headers — The First Line of Defence

What Are HTTP Security Headers?

When a web server responds to a browser's request, it sends back not only the HTML, CSS, and JavaScript that make up the page, but also a set of response headers — key-value pairs that carry metadata about the response. Security headers are a subset of these response headers that instruct the browser to enforce specific security policies on behalf of the server.

Unlike most security controls, which operate on the server side, security headers operate entirely within the browser. The server declares a policy; the browser enforces it. This means they are one of the most cost-effective controls available: a single header value can block entire classes of attack without any changes to application logic.

Why Do Browsers Enforce Them?

Browsers are the interface through which users interact with web applications. They process untrusted content from servers every second. Security headers give server operators a mechanism to say: "Even if my application is compromised, I want the browser to limit what the attacker can do."

For example:

• A Content Security Policy can prevent a cross-site scripting payload from loading a remote script — even if the XSS injection itself was not caught.
• Strict-Transport-Security can prevent the browser from being tricked into connecting over plain HTTP — even if the user types http:// in the address bar.
• X-Frame-Options can prevent the page from being embedded inside a hidden iframe on an attacker's page — blocking clickjacking entirely.

Categories of Security Headers

Real-World Consequences of Missing Headers

The absence of security headers has contributed to some of the most damaging web incidents on record.

In 2018, British Airways suffered a Magecart-style supply-chain attack. Attackers injected a skimming script into the payment page that silently exfiltrated payment card data for approximately 500,000 customers over a period of several weeks. A Content Security Policy that restricted scripts to known, trusted origins would have blocked the exfiltration request the moment the injected script attempted to send data to an external server.

Magecart attacks in general — which have compromised hundreds of e-commerce platforms including Ticketmaster, Newegg, and thousands of smaller retailers — operate by injecting or replacing third-party JavaScript on payment pages. A strict CSP is one of the few controls that provides meaningful protection against this attack pattern after the initial compromise.

Clickjacking attacks against social media platforms were widespread before X-Frame-Options was standardised and widely deployed. Attackers would embed legitimate social media pages in invisible iframes and trick users into clicking hidden "Like" or "Follow" buttons.

SecurityHeaders.com and Grading

The site SecurityHeaders.com (and similar tools such as Mozilla Observatory) analyses the response headers of any publicly accessible URL and assigns a letter grade from A+ down to F based on the presence and configuration of each security header. Many organisations use these grades as a measurable security baseline target. A grade of B or above indicates that the most critical headers are in place.

What You Will Do in This Lab

The interactive panel on the right simulates the HTTP response headers returned by a vulnerable web application at https://vuln-app.example.com. The application currently receives a failing grade.

In this lab you will:

1. Audit the current security headers returned by the simulated application.
2. Identify which headers are missing or misconfigured.
3. Add correct header values for at least four of the missing headers.
4. Bring the security grade from F to B or above.
5. Answer questions about the specific role of HSTS and CSP.

By the end of this lab, you will be able to read a security header audit report, identify the most critical gaps, and apply the correct header values in any server or framework configuration.