What Are Security Headers? | NOC.org

Understanding Security Headers

HTTP security headers are directives sent by a web server in its HTTP responses that instruct the browser to enable or enforce specific security features. When a browser receives these headers, it adjusts its behavior accordingly: restricting which resources can load, preventing the page from being embedded in a frame, enforcing HTTPS connections, or controlling how much referrer information is shared. Security headers form a critical layer of defense that operates entirely in the browser, protecting users even when application-level vulnerabilities exist.

Security headers are effective because they leverage the browser as a security enforcement point. Rather than relying solely on server-side code to prevent attacks, security headers tell the browser to block entire categories of malicious behavior before they can cause harm. This defense-in-depth approach means that even if an attacker finds a way to inject malicious content into a page, properly configured headers can prevent the attack from succeeding.

Why Security Headers Matter

Modern web applications face a wide range of client-side attacks. Cross-site scripting (XSS), clickjacking, MIME-type confusion, protocol downgrade attacks, and data exfiltration through referrer leakage are all threats that security headers help mitigate. Without these headers, browsers use permissive default behaviors that attackers readily exploit.

Beyond security, many organizations are required to implement security headers by compliance frameworks such as PCI DSS, HIPAA, and SOC 2. Security scanning tools and audit reports frequently flag missing headers as vulnerabilities. Implementing them is one of the highest-impact, lowest-effort improvements you can make to your website's security posture.

Key Security Headers

Strict-Transport-Security (HSTS)

HTTP Strict Transport Security (HSTS) tells browsers to only connect to your site over HTTPS. Once a browser receives this header, it will automatically upgrade all HTTP requests to HTTPS for the specified duration, even if the user types http:// in the address bar or clicks an HTTP link. This prevents protocol downgrade attacks and SSL stripping, where an attacker intercepts the initial HTTP connection before it redirects to HTTPS.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The max-age value specifies how long (in seconds) the browser should remember to enforce HTTPS. The includeSubDomains directive extends the policy to all subdomains. The preload directive indicates intent to be included in the browser's built-in HSTS preload list.

Content-Security-Policy (CSP)

Content Security Policy is the most powerful security header available. CSP defines a whitelist of approved sources for scripts, styles, images, fonts, frames, and other resources. If a resource does not match an approved source, the browser blocks it. This is highly effective against XSS attacks because even if an attacker injects a malicious script tag, the browser refuses to execute it unless the script source is explicitly allowed by the policy.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'

CSP is the most complex security header to deploy correctly because it requires a thorough understanding of all the resources your application loads. A misconfigured CSP can break legitimate functionality.

X-Frame-Options

X-Frame-Options controls whether your page can be embedded in a frame, iframe, or object tag on another site. This header is the primary defense against clickjacking attacks, where an attacker overlays a transparent iframe of your site on top of a malicious page to trick users into clicking hidden elements.

X-Frame-Options: DENY

The three possible values are:

• DENY: The page cannot be displayed in a frame, regardless of the framing site.
• SAMEORIGIN: The page can only be framed by pages on the same origin.
• ALLOW-FROM uri: The page can only be framed by the specified origin (limited browser support; CSP's frame-ancestors directive is preferred).

X-Content-Type-Options

This header prevents browsers from MIME-sniffing a response away from the declared content type. Without it, browsers may interpret a file differently than the server intended, potentially executing a text file as JavaScript or treating an image as HTML. This is especially dangerous when user-uploaded content is served from your domain.

X-Content-Type-Options: nosniff

The only valid value is nosniff. This header works in conjunction with proper MIME type configuration to ensure browsers respect the content type declared by the server.

Referrer-Policy

Referrer-Policy controls how much referrer information the browser sends when navigating from your site to another. The HTTP Referer header (note the historical misspelling) can leak sensitive information such as URL parameters, internal page paths, and session tokens. Referrer-Policy lets you limit or suppress this information.

Referrer-Policy: strict-origin-when-cross-origin

Common values include:

• no-referrer: Never send referrer information.
• same-origin: Send referrer only for same-origin requests.
• strict-origin-when-cross-origin: Send full URL for same-origin requests, only the origin for cross-origin requests over HTTPS, and nothing for downgrade requests. This is the recommended default.
• no-referrer-when-downgrade: Send referrer for same-protocol requests but not for HTTPS-to-HTTP downgrades.

Permissions-Policy

Permissions-Policy (formerly Feature-Policy) controls which browser features and APIs your page and its embedded content can use. This includes access to the camera, microphone, geolocation, payment APIs, and more. By restricting these features, you reduce the attack surface if your page is compromised or if malicious third-party content is loaded.

Permissions-Policy: camera=(), microphone=(), geolocation=(self), payment=()

An empty parentheses () means the feature is disabled for all contexts. (self) allows the feature only for same-origin content. You can also specify specific origins that are allowed to use each feature.

Browser Enforcement

Security headers are enforced entirely by the browser. The server sends the headers, and the browser decides how to act on them. This means security headers only protect users whose browsers support them. All modern browsers (Chrome, Firefox, Safari, Edge) support the major security headers. Legacy browsers may ignore some headers, but this should not prevent you from deploying them, as the vast majority of your traffic will be from modern browsers.

It is also important to understand that security headers do not replace proper server-side security practices. They are an additional layer of defense. A Content Security Policy cannot fix a SQL injection vulnerability, and HSTS cannot protect against a server misconfiguration. Security headers complement application security, they do not substitute for it.

Testing Your Headers

Several tools can analyze your security headers and provide a grade or report. Configuring security headers correctly requires testing to ensure they do not break legitimate functionality. Online tools like securityheaders.com scan your site's response headers and identify missing or misconfigured headers. Browser developer tools (Network tab) also show all response headers for manual inspection.

A Web Application Firewall (WAF) can also add or enforce security headers at the edge, which is useful when you cannot modify the origin server's configuration directly.

Summary

Security headers are a fundamental part of web security that protect users by instructing browsers to enforce security policies. Implementing HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy significantly reduces your exposure to client-side attacks including XSS, clickjacking, MIME confusion, and data leakage. Every website should deploy these headers as part of a defense-in-depth security strategy.

Need help securing your infrastructure? Explore NOC.org plans to get started.