Security on Your Website: What Security Headers Are and How to Configure Them Step by Step

Security headers are instructions that your server sends to the browser to indicate how it should handle the content of your page. They are one of the most effective defenses against attacks such as XSS, clickjacking, or MIME‑type spoofing [1][3]. In this article you will discover which headers are essential, how to check their presence, and how to add them on the most common servers without hassle.

1. Why Security Headers Are Essential?

Browsers interpret each HTTP response according to the directives they receive. When a security header is missing or misconfigured, the client is exposed to known vulnerabilities. For example:

These headers not only block active attacks, they also reduce the error surface by forcing the browser to follow strict rules [2][5]. In SaaS environments or modern applications, the absence of several of them is usually considered a high‑priority finding in security audits [6].

2. Headers Every Website Should Have

Below are the seven most recommended headers, with a brief explanation of their function and the typical value that is commonly applied:

These values appear in practical guides and configuration examples for Apache, Nginx, and frameworks like Next.js [4][7].

3. Verify the Current Headers of Your Site

Before adding or modifying any directive, it is essential to know which headers are already present. Several free tools are available:

• cURL: curl -I https://yoursite.com shows the full header response.
• Online security scanners: sites such as securityheaders.com analyze the response and generate a scored report.
• Browser extensions: “Security Headers” for Chrome/Firefox lets you inspect headers in real time.

Run one of these tests and compare the result with the table above. If a header is missing, note it; if it is present but with a weak value, decide whether to strengthen it.

4. Step‑by‑Step Configuration on the Most Common Servers

Below are ready‑to‑copy examples. Replace yoursite.com with your domain and adjust the values to suit your needs.

4.1 Apache (.htaccess or httpd.conf)

Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://apis.google.com; object-src 'none'"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always set X-Frame-Options "DENY"
Header set X-Content-Type-Options "nosniff"
Header set Referrer-Policy "no-referrer-when-downgrade"
Header set Permissions-Policy "geolocation=(), camera=()"
Header set Cross-Origin-Opener-Policy "same-origin"
Header set Cross-Origin-Embedder-Policy "require-corp"

Save the changes and restart Apache (systemctl restart apache2).

4.2 Nginx (server block)

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://apis.google.com; object-src 'none'";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header Referrer-Policy "no-referrer-when-downgrade";
add_header Permissions-Policy "geolocation=(), camera=()";
add_header Cross-Origin-Opener-Policy "same-origin";
add_header Cross-Origin-Embedder-Policy "require-corp";

Reload the configuration (nginx -s reload).

4.3 Next.js / Vercel (next.config.js)

module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          { key: 'Content-Security-Policy', value: "default-src 'self'; script-src 'self' https://apis.google.com; object-src 'none'" },
          { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
          { key: 'X-Frame-Options', value: 'DENY' },
          { key: 'X-Content-Type-Options', value: 'nosniff' },
          { key: 'Referrer-Policy', value: 'no-referrer-when-downgrade' },
          { key: 'Permissions-Policy', value: 'geolocation=(), camera=()' },
          { key: 'Cross-Origin-Opener-Policy', value: 'same-origin' },
          { key: 'Cross-Origin-Embedder-Policy', value: 'require-corp' },
        ],
      },
    ];
  },
};

Deploy again and verify with the tool of your choice.

These snippets come from guides that include copy‑ready code for Apache, Nginx, and Next.js [4][7].

5. Best Practices and Final Considerations

1. Incremental testing: enable one header at a time and verify that your site’s functionality remains intact. CSP, in particular, can block legitimate scripts if the policy is too restrictive.
2. Use CSP “report‑only” mode first: Content-Security-Policy-Report-Only. This lets you receive reports without blocking content.
3. Keep HSTS up to date: once you enable preload, your domain will be on browsers’ preload lists; revoking it is difficult.
4. Document changes: record in your infrastructure repository (e.g., in configuration files) which values you use and why.
5. Review regularly: browsers and standards evolve; an annual audit ensures you don’t retain obsolete or vulnerable headers.

Conclusion

Security headers are a simple yet powerful defense layer that any website should implement. With just a few server‑configuration tweaks you can block common attack vectors, improve user privacy, and meet security‑audit requirements.

Ready to harden your site? Start today by checking your current headers, choose the values that best fit your architecture, and apply the snippets we’ve shared. Each added header is another step toward a more secure online presence.

Sources and references

• Headers de Seguridad: Qué Son y Cómo Configurarlos en tu Aplicación Web (Rodalex Anderson)
• Security Headers: Qué Son y Cómo Configurarlos Correctamente (Elantia)
• Qué headers de seguridad debería tener tu web — Weaking
• Security headers HTTP: la protección que la mayoría de SaaS olvida (VibeAuditt)
• Web Security Headers | Guía | StackPractices