HTTP Security Headers and HTTPS: A Practical Setup Guide

HTTPS everywhere

HTTPS encrypts traffic between the browser and your server, so people on the same network, such as a cafe Wi-Fi in Bengaluru or an airport in Dubai, cannot read or alter it. It is required for secure cookies, modern browser features and user trust. Free certificates from Let's Encrypt, together with automated renewal tools such as Certbot, make HTTPS available for every site. Many hosting platforms and CDNs issue and renew certificates automatically.

Serve every page and API over HTTPS, not just the login page, and redirect plain HTTP requests to HTTPS. Use the TLS configuration recommended by your server or platform rather than hand-picking ciphers, and automate certificate renewal with monitoring so an expired certificate never takes your site down. Free tools such as the SSL Labs server test can check your configuration and point out weaknesses.

What security headers do

Security headers are instructions your server sends to the browser to enable extra protections. They do not replace secure code, but they reduce the impact of mistakes. MDN Web Docs explains each header in detail and is the best reference to keep open while configuring them. Add headers in one central place, such as your web server, reverse proxy or framework middleware, so every response gets them consistently.

• Strict-Transport-Security: tells browsers to use HTTPS only for your site
• Content-Security-Policy: limits where scripts, styles and other resources can load from
• X-Content-Type-Options: stops browsers guessing content types
• Referrer-Policy: controls how much URL information is shared with other sites
• Permissions-Policy: turns off browser features such as camera access you do not use
• frame-ancestors in CSP: prevents your pages being embedded to trick users into clicks

An example configuration

The nginx snippet below shows the general pattern: redirect HTTP to HTTPS, then add headers to the HTTPS server. The values are examples only. A strict Content Security Policy like the one shown will break pages that load scripts from other domains, so you must adapt it to your site. Equivalent settings exist for Apache, Caddy, cloud load balancers and framework middleware such as Helmet for Express.

# Illustrative nginx snippet. Values are examples to adapt,
# not recommendations for every site. See MDN for each header.
server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate and ssl_certificate_key lines go here

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header Content-Security-Policy "default-src 'self'; frame-ancestors 'none'" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
}

Rolling out Content Security Policy safely

Content Security Policy is the most powerful header and the one most likely to break things. Roll it out gradually. Start with the Content-Security-Policy-Report-Only header, which reports violations without blocking anything, and collect reports for a while. Use them to build a list of sources your site legitimately uses, such as your analytics or payment provider. Remove inline scripts where possible, or use nonces, so you can avoid allowing unsafe inline code.

Once reports are quiet, switch to the enforcing header and keep monitoring. Treat the policy as part of the codebase: when a developer adds a new third-party script, the policy change goes through review too. Check your headers after each deployment with browser developer tools or an online header scanner. On XDQ Labs projects, a header check runs in the deployment pipeline so missing headers fail the release rather than reaching users.

Check your understanding