Website Security Headers: HTTPS, CSP & Hardening

By the end of this walkthrough, you should have a website with verified HTTPS enforcement, a working Content Security Policy, a published security.txt file, and a short list of response headers that close off some of the most common attack paths. None of this requires a dedicated security team. It requires access to your DNS panel, your web server or hosting dashboard, and roughly an hour of uninterrupted time.

Before you start, confirm three things: administrative access to your hosting control panel or server, the ability to edit server configuration files or add HTTP headers through your CMS or CDN, and a staging environment or low-traffic window to test changes without disrupting live visitors. If you run an e-commerce site that processes card payments, also check who is responsible for your SSL certificate renewal. Letting it lapse during a sales period is recoverable, but it is a painful way to learn who owns that task.

Confirm HTTPS Is Actually Enforced, Not Just Available

Plenty of businesses assume that a padlock icon in the browser bar means HTTPS is properly configured. In practice, a surprising number of sites still accept plain HTTP connections on port 80 and only redirect some pages, which leaves login forms or checkout pages reachable over an unencrypted connection whenever someone types the address manually or follows an old link.

Check your server or hosting panel for a permanent redirect rule that sends every HTTP request to HTTPS, not only the homepage. On Apache, this usually lives in your .htaccess file. On Nginx, it is a server block directive. On managed hosting, it is often a toggle labeled something like "force HTTPS."

To verify it, open your site using http:// explicitly, including a deep page such as a product or contact URL, and confirm the browser lands on the https:// version with a 301 status code. Browser developer tools, specifically the Network tab, show the status code directly. If any page returns 200 over plain HTTP instead of redirecting, that page is still exposed.

Add HSTS So Browsers Stop Asking

HTTP Strict Transport Security, or HSTS, is a response header that tells the browser to never attempt an HTTP connection to your domain again, even if someone types http:// or clicks an old bookmark. Without it, every visit technically starts with a vulnerable HTTP request that only becomes safe once the redirect finishes.

Add the header Strict-Transport-Security: max-age=31536000; includeSubDomains to your server configuration, or through your CDN if you use one. Start with a shorter max-age value while testing, then extend it once you are confident the HTTPS setup is stable across every subdomain.

To verify it, inspect the response headers of your homepage in browser developer tools and confirm Strict-Transport-Security is present with the expected max-age value. Hold off on the preload directive until HSTS has run correctly for a few weeks, since preload lists are slow and difficult to reverse once submitted.

Should You Write a Content Security Policy From Scratch?

A Content Security Policy, or CSP, is a browser-level instruction that restricts which domains your site is allowed to load scripts, styles, images, or fonts from. It significantly limits what an attacker can do even after managing to inject malicious code into a page. Writing one from scratch is reasonable for a site with no inline scripts and few third-party integrations; for a page loaded with tracking pixels, chat widgets, and marketplace scripts, it becomes a multi-step project rather than a single header.

Start in report-only mode using Content-Security-Policy-Report-Only instead of the enforcing version. List every domain your site actually pulls resources from, including analytics providers, payment gateway scripts, and font services, and build the policy from that real list rather than guessing.

Run the site for several days in report-only mode and review the violation reports sent to your reporting endpoint or browser console. Once that log stops flagging legitimate resources, switch the header from report-only to enforcing.

Set the Supporting Headers That Close Smaller Gaps

CSP and HSTS get most of the attention, but a handful of smaller headers close gaps that are just as easy for an attacker to exploit, particularly around clickjacking and content sniffing.

• X-Content-Type-Options: nosniff stops browsers from guessing a file's type and executing it differently than intended, which matters most for file upload features.
• X-Frame-Options: SAMEORIGIN, or the frame-ancestors directive in your CSP, prevents your pages from being embedded in an invisible iframe on another site, a technique used in clickjacking attacks.
• Referrer-Policy: strict-origin-when-cross-origin limits how much of your URL path leaks to external sites when a visitor clicks an outbound link.
• Permissions-Policy restricts access to browser features like camera, microphone, or geolocation that your site does not actually need.

Add these headers through the same configuration file or CDN rule set you used for HSTS. To verify, use a header-inspection tool or your browser's Network tab and confirm each header appears exactly once per response. Duplicate headers coming from both your CMS and your CDN are a common source of confusing, hard-to-trace behavior.

Publish a security.txt File

A security.txt file is a plain text document placed at /.well-known/security.txt that tells a researcher who discovers a vulnerability on your site how to report it responsibly, instead of posting it publicly or selling the information. For any company handling customer data or payment information, this is a low-effort way to give good-faith researchers a direct channel before a problem becomes public.

Create a text file listing a contact email or reporting URL, an optional expiry date for the file itself, and a link to your policy if one exists. Upload it to the /.well-known/ directory of your domain.

To verify it, visit yourdomain.com/.well-known/security.txt directly in a browser and confirm the file loads as plain text with the correct content, not a 404 error or your CMS's default error page.

Test the Whole Configuration Together

Headers configured individually can still conflict once combined, especially when a CDN, a web application firewall, and your CMS are all trying to set headers on the same response.

Run your domain through a header-analysis tool that checks HTTPS configuration, certificate validity, HSTS, CSP syntax, and the supporting headers in one pass. Note anything reported as missing, duplicated, or malformed.

Fix the highest-severity issue first, usually a missing or broken HSTS or CSP header, then re-run the same test and confirm that specific issue is resolved before moving to the next item. Testing after each individual change, instead of batching several together, makes it far easier to pinpoint which change broke something if a page suddenly stops loading a script or font correctly.

The Mistake Teams Make and How to Recover From It

The most common mistake is enabling an enforcing CSP too early, before confirming every legitimate script source. This breaks checkout pages, embedded maps, or chat widgets without an obvious error message for the end user. The site looks fine to whoever is testing it internally, because their browser cache still holds the old resources, while new visitors land on a broken page.

Recovery is straightforward if you catch it quickly. Switch the CSP header back to report-only mode immediately, which restores full functionality while you review what was blocked. Check your violation reports or browser console errors from affected sessions, add the missing domains to your policy, run it in report-only mode again for a few days, and only re-enable enforcement once the violation log is clean. In our own web design and development projects, we treat that report-only period as non-negotiable, precisely because skipping it makes the rollback so disruptive.

Final Hardening Checklist

Before considering this work complete, confirm each of the following against your live site, not just your staging environment.

• Every HTTP request redirects to HTTPS with a 301 status, on every page, not just the homepage.
• The Strict-Transport-Security header is present with an appropriate max-age value.
• Your Content Security Policy has run in report-only mode with a clean violation log before being switched to enforcing mode.
• X-Content-Type-Options, X-Frame-Options or frame-ancestors, Referrer-Policy, and Permissions-Policy headers are all present and not duplicated.
• security.txt loads correctly at /.well-known/security.txt with current contact information.
• A header-analysis tool shows no missing or malformed headers on your production domain.

If your team doesn't have the internal capacity to own this configuration long-term, particularly for an e-commerce platform where a misconfigured CSP can silently break the checkout flow, it's worth having it reviewed as part of a dedicated engagement. You can see how we scope this kind of work on our services page, where configuration reviews are typically defined as a fixed, well-scoped task rather than open-ended work.

If you would rather have this assessed and implemented directly on your live environment, reach out through our get a quote page and we can walk through what your current setup looks like before proposing next steps.