Website Security Headers Explained: A Practical Checklist

What is a website security header?

When a browser requests a page, the server returns a response. Along with the page content and status code, that response can include HTTP headers. Some headers tell the browser how to handle HTTPS, scripts, embedded frames, content types, referrers, permissions, and cookies.

A website security header check looks at the headers actually returned by the site. The result should describe what was observed—not assume that a missing header automatically proves a site has been compromised.

1. HTTPS and Strict-Transport-Security (HSTS)

HTTPS encrypts data in transit between the browser and the website. HSTS tells a browser that it should use HTTPS for future connections to the domain for the period specified by the site.

What to review: confirm the site consistently serves HTTPS and redirects HTTP requests appropriately. Then review whether the response includes a suitable Strict-Transport-Security policy.

2. Content-Security-Policy (CSP)

CSP lets a site define where a browser may load scripts, styles, images, fonts, frames, and other resources. A carefully designed policy can reduce the impact of some injected-content attacks.

What to review: check whether the policy reflects the resources the site actually needs. A policy that is too broad may offer little protection; one that is too strict may break checkout, analytics, fonts, or other site features.

For a new or changed policy, consider testing with Content-Security-Policy-Report-Only before enforcing it. Review reports and fix legitimate dependencies before switching to enforcement.

3. X-Content-Type-Options

The X-Content-Type-Options: nosniff header tells browsers not to guess certain resource types when the server supplies a content type. This helps reduce risks created when browsers interpret a resource differently from the way the server intended.

What to review: check whether the header is present and whether the server sends accurate content types for scripts, stylesheets, and other resources.

4. Referrer-Policy

When a person follows a link, browsers may send referrer information describing the page they came from. Referrer-Policy controls how much of that information is shared with the destination.

What to review: choose a policy that balances measurement needs and privacy. A common modern starting point is strict-origin-when-cross-origin, but a site's requirements should guide the choice.

5. Framing protection

Pages that can be embedded in frames on other sites may be exposed to clickjacking, where a visitor is tricked into interacting with a hidden or misleading interface.

What to review: use CSP's frame-ancestors directive to define which sites may embed the page. X-Frame-Options is also used by many sites and older browsers. The correct setting depends on whether the site intentionally allows framing.

6. Permissions-Policy

Permissions-Policy lets a site control whether browser features—such as camera, microphone, geolocation, or other capabilities—may be used by the page or embedded frames.

What to review: restrict features the site does not need, while testing legitimate workflows such as video calls, maps, or location-based functionality.

7. Cookie security attributes

When a server sets a cookie, attributes help determine when the browser sends it and how scripts can access it.

• Secure: sends the cookie only over secure connections.
• HttpOnly: prevents ordinary browser scripts from reading the cookie.
• SameSite: controls when the browser sends the cookie in cross-site contexts.

What to review: inspect cookies actually set by the site and choose attributes appropriate to each cookie's purpose. A homepage response that sets no cookies may not provide enough evidence to assess cookies used later in a login or checkout flow.

8. CORS is about cross-origin browser access

Cross-Origin Resource Sharing (CORS) is a browser mechanism that controls whether scripts running on one origin can read responses from another origin. It is not a general-purpose firewall or a replacement for authentication.

What to review: allow only the origins and methods required for the application's intended browser workflows. A wildcard origin is not automatically a vulnerability for every public resource; risk depends on the data, credentials, and response behavior involved.

How can you check a website's response headers?

You can inspect the main document request in your browser's developer tools under the Network panel. Select the document request and review its response headers. This helps you see what the browser actually received.

From a terminal, this command makes a GET request and prints the response headers while discarding the response body:

Replace example.com with a site you own or are authorized to check. Redirects, caching layers, hosting platforms, and application routes can affect which response you observe. Compare the final page response with any relevant application-specific routes.

A sensible review checklist

• Confirm HTTPS works across the pages and subdomains that matter.
• Review HSTS carefully before enabling a long duration or subdomain coverage.
• Build CSP around the site's actual scripts and services; test before enforcing.
• Check content types, referrer behavior, framing rules, and browser permissions.
• Inspect cookies in the flows where they are set, including login and checkout.
• Review CORS based on the data and origins involved, not just whether a wildcard appears.
• Recheck the site after changes and verify that important site features still work.