DEV Community

Cover image for HTTP Security Headers Explained: A Practical Guide for Developers
az hala
az hala

Posted on

HTTP Security Headers Explained: A Practical Guide for Developers

#security #javascript #webdev

HTTP Security Headers Explained: A Practical Guide for Developers

A website can use HTTPS, strong passwords, authentication, and secure application code and still have security weaknesses that browsers can help mitigate.

One of the simplest ways to add another layer of protection is through HTTP security headers.

Security headers allow a web server to tell the browser how certain resources should be handled, whether a page can be embedded, which origins can load content, and how much information should be included in referrer requests.

In this guide, we'll look at the most important security headers, explain what they do, and show practical configuration examples for modern websites.

What Are HTTP Security Headers?

HTTP security headers are response headers sent by a web server to a browser.

For example, a server might return:

HTTP/2 200
Content-Type: text/html; charset=UTF-8
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Enter fullscreen mode Exit fullscreen mode

The browser reads these headers and adjusts its behavior based on the policies provided by the server.

Security headers can help reduce the impact of several common web security problems, including:

  • Cross-site scripting (XSS)
  • Clickjacking
  • MIME-type confusion
  • Unsafe resource loading
  • Unnecessary referrer information exposure
  • Some cross-origin security risks

However, security headers are not a replacement for secure application development.

You still need proper authentication, authorization, input validation, output encoding, secure session management, HTTPS, dependency management, and other security practices.

Think of security headers as an additional defensive layer.

1. Content-Security-Policy (CSP)

Content-Security-Policy, commonly called CSP, is one of the most powerful security headers available to web developers.

CSP allows you to control where browsers can load resources such as:

  • JavaScript
  • CSS
  • Images
  • Fonts
  • Frames
  • Media
  • Connections

A very simple policy is:

Content-Security-Policy: default-src 'self'
Enter fullscreen mode Exit fullscreen mode

This tells the browser that resources should generally come from the same origin.

A more realistic example could be:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:;
Enter fullscreen mode Exit fullscreen mode

The exact policy depends entirely on the application.

For example, if your website uses third-party analytics, payment services, video embeds, or CDNs, those resources may need to be explicitly allowed.

Why CSP Matters

One important benefit of CSP is reducing the impact of certain XSS attacks.

If an attacker manages to inject a script into a page but the script violates the site's CSP, the browser can refuse to execute it.

That makes CSP an important defense-in-depth mechanism.

Test CSP Before Enforcing It

A restrictive CSP can accidentally break a website.

For an existing application, you can test a policy with:

Content-Security-Policy-Report-Only: default-src 'self'
Enter fullscreen mode Exit fullscreen mode

Report-only mode allows developers to identify policy violations without immediately blocking the resources.

Once the policy has been tested and adjusted, it can be moved to the normal Content-Security-Policy header.

2. Strict-Transport-Security (HSTS)

HTTP Strict Transport Security tells browsers that a website should be accessed using HTTPS.

A basic configuration looks like this:

Strict-Transport-Security: max-age=31536000
Enter fullscreen mode Exit fullscreen mode

The value is expressed in seconds.

For example, 31536000 represents one year.

A configuration may also include subdomains:

Strict-Transport-Security: max-age=31536000; includeSubDomains
Enter fullscreen mode Exit fullscreen mode

Be Careful With HSTS

HSTS should not be enabled blindly.

Before using includeSubDomains, make sure the relevant subdomains are correctly configured for HTTPS.

Otherwise, users could have problems accessing services that still depend on HTTP.

HSTS is particularly useful for helping prevent protocol downgrade attacks and ensuring that browsers consistently use HTTPS after receiving the policy.

3. X-Content-Type-Options

This is one of the simplest security headers to configure.

X-Content-Type-Options: nosniff
Enter fullscreen mode Exit fullscreen mode

The nosniff value tells browsers not to try to guess the MIME type of certain resources.

Web servers should correctly specify the content type of files such as JavaScript, CSS, images, and other resources.

For many websites, adding this header is a straightforward security improvement.

4. Referrer-Policy

When a browser navigates from one page to another, it can send information about the previous page through the Referer request header.

Depending on the URL structure of your website, that information may reveal more than you want to share.

A commonly useful policy is:

Referrer-Policy: strict-origin-when-cross-origin
Enter fullscreen mode Exit fullscreen mode

This generally provides more limited information when navigating between different origins while retaining useful referrer information for same-origin requests.

Other policies include:

Referrer-Policy: no-referrer
Enter fullscreen mode Exit fullscreen mode

and:

Referrer-Policy: same-origin
Enter fullscreen mode Exit fullscreen mode

The right choice depends on the privacy and analytics requirements of your application.

5. Permissions-Policy

Modern browsers expose powerful features such as:

  • Camera
  • Microphone
  • Geolocation
  • Sensors
  • Fullscreen
  • USB
  • Other browser capabilities

Permissions-Policy allows developers to control which origins can use specific features.

For example:

Permissions-Policy: camera=(), microphone=(), geolocation=()
Enter fullscreen mode Exit fullscreen mode

This configuration disables camera, microphone, and geolocation access for the document.

If your application does not need a browser capability, restricting it can reduce unnecessary exposure.

If the application actually requires a feature, the policy should be configured accordingly.

6. X-Frame-Options and Clickjacking

Clickjacking occurs when an attacker attempts to trick users into interacting with a website through an embedded frame.

A traditional defense is:

X-Frame-Options: DENY
Enter fullscreen mode Exit fullscreen mode

This prevents the page from being framed.

Another option is:

X-Frame-Options: SAMEORIGIN
Enter fullscreen mode Exit fullscreen mode

This allows framing by pages from the same origin.

Modern applications can also use CSP's frame-ancestors directive:

Content-Security-Policy: frame-ancestors 'self'
Enter fullscreen mode Exit fullscreen mode

The exact configuration depends on whether your website needs to be embedded by other pages.

7. Cross-Origin Security Headers

Modern web applications may also use headers that control relationships between documents and resources from different origins.

Three headers you may encounter are:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Enter fullscreen mode Exit fullscreen mode

These headers have different purposes.

Cross-Origin-Opener-Policy

COOP controls how a document interacts with browsing contexts from other origins.

Cross-Origin-Opener-Policy: same-origin
Enter fullscreen mode Exit fullscreen mode

Cross-Origin-Resource-Policy

CORP allows a resource to specify which origins can load it.

Cross-Origin-Resource-Policy: same-origin
Enter fullscreen mode Exit fullscreen mode

Cross-Origin-Embedder-Policy

COEP controls whether cross-origin resources can be embedded under specific conditions.

Cross-Origin-Embedder-Policy: require-corp
Enter fullscreen mode Exit fullscreen mode

These policies can affect third-party resources, so they should be introduced carefully and tested against the actual application.

A Practical Starting Configuration

A basic security configuration might look like this:

Content-Security-Policy: default-src 'self'
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
X-Frame-Options: SAMEORIGIN
Enter fullscreen mode Exit fullscreen mode

But this should not be treated as a universal copy-and-paste configuration.

Every application is different.

For example, a website that uses Google Fonts, YouTube, analytics platforms, advertising networks, payment gateways, or external JavaScript libraries may require a more specific CSP.

Always test your configuration before deploying it to production.

Configuring Security Headers With Apache

Apache HTTP Server can configure response headers using mod_headers.

For example:

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>
Enter fullscreen mode Exit fullscreen mode

HSTS can be added after HTTPS has been correctly configured:

Header always set Strict-Transport-Security "max-age=31536000"
Enter fullscreen mode Exit fullscreen mode

Make sure the relevant Apache modules and configuration permissions are available on your hosting environment.

Configuring Security Headers With Nginx

Nginx uses the add_header directive.

For example:

add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
Enter fullscreen mode Exit fullscreen mode

HSTS can be configured as:

add_header Strict-Transport-Security "max-age=31536000" always;
Enter fullscreen mode Exit fullscreen mode

Again, verify your HTTPS configuration before enabling HSTS.

Configuring Headers in Node.js

If you're building a Node.js application, you can set response headers in application code.

A simple example is:

app.use((req, res, next) => {
  res.setHeader("X-Content-Type-Options", "nosniff");

  res.setHeader(
    "Referrer-Policy",
    "strict-origin-when-cross-origin"
  );

  res.setHeader("X-Frame-Options", "SAMEORIGIN");

  next();
});
Enter fullscreen mode Exit fullscreen mode

For larger applications, security middleware can make header management easier.

However, developers should still understand what the individual headers actually do.

Using middleware without understanding the policies can make debugging much harder.

How to Check Security Headers

You don't necessarily need a specialized tool to inspect HTTP response headers.

One of the simplest methods is using curl:

curl -I https://example.com
Enter fullscreen mode Exit fullscreen mode

You may see something similar to:

HTTP/2 200
content-type: text/html
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=31536000
Enter fullscreen mode Exit fullscreen mode

You can also inspect headers directly from your browser.

Open Developer Tools, go to the Network tab, reload the page, select the main document request, and inspect the Response Headers section.

This is especially useful when troubleshooting a missing or incorrectly configured header.

Automating Security Header Audits

If you regularly work with multiple websites, manually checking every response becomes repetitive.

A security header checker can automate the process.

A basic scanner can:

  1. Accept a URL.
  2. Make an HTTP or HTTPS request.
  3. Follow redirects.
  4. Read the final response headers.
  5. Check important security policies.
  6. Identify missing headers.
  7. Produce a report or score.

A simplified Node.js example might look like:

const response = await fetch(url);

const headers = response.headers;

const result = {
  contentSecurityPolicy:
    headers.get("content-security-policy"),

  strictTransportSecurity:
    headers.get("strict-transport-security"),

  contentTypeOptions:
    headers.get("x-content-type-options"),

  referrerPolicy:
    headers.get("referrer-policy"),

  permissionsPolicy:
    headers.get("permissions-policy")
};

console.log(result);
Enter fullscreen mode Exit fullscreen mode

A production-grade scanner requires much more than this small example.

Important considerations include:

  • Redirect limits
  • Request timeouts
  • TLS certificate validation
  • DNS resolution
  • IPv4 and IPv6 handling
  • Private network protection
  • SSRF prevention
  • Rate limiting
  • Abuse prevention
  • Maximum response sizes
  • Error handling

If a tool accepts arbitrary URLs, SSRF protection is especially important.

A server should not blindly make requests to internal services or private network addresses.

Security Headers and Technical SEO

Security headers are primarily security mechanisms rather than direct search-engine ranking factors.

However, security and technical SEO can overlap in several areas.

For example, incorrect HTTPS configuration can cause redirect problems.

An overly restrictive CSP can prevent important resources from loading.

Broken redirects can interfere with crawling and canonicalization.

Mixed-content problems can affect page functionality.

Server reliability can also influence how users and automated crawlers experience a website.

This means security configuration should be considered alongside other technical website practices such as:

  • Crawlability
  • HTTPS
  • Canonical URLs
  • Structured data
  • Mobile rendering
  • Page performance
  • Internal linking
  • Server responses

For developers and website owners working on broader technical SEO, understanding how the server and browser interact is just as important as optimizing page content.

Common Security Header Mistakes

Mistake 1: Copying a CSP Without Testing

CSP is powerful, but an overly restrictive policy can break legitimate resources.

Always test the policy against your actual application.

Mistake 2: Enabling HSTS Too Early

HSTS can create accessibility problems if parts of your infrastructure are not ready for HTTPS.

Verify your domain and relevant subdomains before deploying an aggressive HSTS policy.

Mistake 3: Adding Every Header You Find

More headers do not automatically mean better security.

Security policies should address the actual requirements of your application.

A poorly configured policy can create compatibility problems without providing meaningful protection.

Mistake 4: Forgetting Third-Party Resources

Modern websites often depend on external services.

Your CSP and other policies should account for legitimate third-party resources without unnecessarily allowing everything.

Mistake 5: Testing Only the Homepage

Different routes can be handled differently.

For example:

/
 /login
 /dashboard
 /api/
 /static/
Enter fullscreen mode Exit fullscreen mode

may be served through different application layers, proxies, or services.

Important routes should therefore be included in your security testing.

Security Header Audit Checklist

Use this checklist when reviewing a website:

  • [ ] HTTPS is correctly configured
  • [ ] HSTS is appropriate for the domain
  • [ ] CSP is present and tested
  • [ ] X-Content-Type-Options is configured
  • [ ] Referrer-Policy is configured
  • [ ] Permissions-Policy has been reviewed
  • [ ] Clickjacking protection is configured
  • [ ] Cross-origin policies are reviewed where necessary
  • [ ] Redirects behave correctly
  • [ ] Third-party resources are accounted for
  • [ ] Important routes return the expected headers
  • [ ] Security policies do not break legitimate functionality

Final Thoughts

HTTP security headers provide an additional layer of browser-enforced protection for modern websites.

The most important lesson is not to copy a list of headers and assume the website is secure.

Instead, use a process:

Understand → Configure → Test → Monitor → Improve

Start with the policies that make sense for your application.

If you manage multiple websites, automating security-header checks can also save time and make configuration problems easier to identify.

Building a small security-header scanner is an excellent practical project for developers because it combines HTTP, networking, backend development, browser security, and real-world web infrastructure.

Security headers are only one part of a secure website, but they are a practical and useful place to start.

Further Reading

For deeper information, developers should consult authoritative documentation and security references such as:

  • OWASP HTTP Security Response Headers Cheat Sheet
  • MDN Web Docs
  • Content Security Policy documentation
  • HTTP Strict Transport Security documentation

Always verify security recommendations against current browser and server documentation before deploying them to production.
If you're working on the broader technical side of website SEO, you can also use this guide from AzkiWeb:
https://azkiweb.com/seo-website
For developers who want to go beyond security headers and improve the overall technical foundation of a website, see AzkiWeb's guide to web design and development:
https://azkiweb.com/web-design

Top comments (0)