Security Headers for eCommerce: The Checklist Most Agencies Skip

Your eCommerce store handles customer names, addresses, payment details, and browsing behaviour. You've got an SSL certificate and PCI compliance sorted. But if you haven't configured your HTTP security headers, you're leaving doors wide open that most attackers know how to walk through.

Security headers are HTTP response headers that tell the browser how to behave when handling your site's content. They're free to implement, take minutes to configure, and protect against some of the most common web attacks. Yet most agencies skip them entirely.

Why Security Headers Matter for eCommerce

eCommerce stores are high-value targets. They process payment information, store customer data, and handle financial transactions. A single cross-site scripting (XSS) attack can inject a card skimmer into your checkout. A clickjacking attack can trick customers into making purchases they didn't intend. These aren't theoretical risks—they happen regularly.

For stores handling card payments, PCI DSS 4.0 now explicitly recommends security headers as part of your compliance posture. While they're not a hard requirement on their own, auditors increasingly look for them during assessments.

Content-Security-Policy (CSP)

This is the most important and most complex security header. CSP tells the browser exactly which resources are allowed to load on your page—scripts, styles, images, fonts, frames, everything. If a resource isn't whitelisted, the browser blocks it.

For eCommerce, CSP is your primary defence against Magecart-style attacks where malicious JavaScript is injected to skim credit card data. If the attacker's script domain isn't in your CSP, the browser won't execute it.

CSP for Shopify Stores

Shopify controls the response headers on the storefront, so you can't set CSP directly for your main store pages. However, you can set CSP for your headless storefronts (Hydrogen, custom Next.js builds), custom apps, and any pages served from your own infrastructure. For Shopify-hosted stores, focus on the headers you can control and use Shopify's built-in security features.

CSP for BigCommerce / Custom Builds

If you control your hosting (headless builds, custom platforms), implement CSP in your server configuration or middleware. Start in report-only mode (Content-Security-Policy-Report-Only) to see what would break before enforcing. Monitor reports for a week, fix violations, then switch to enforcement.

X-Frame-Options

This header prevents your site from being embedded in an iframe on another domain. Without it, attackers can overlay your site with invisible elements and trick users into clicking things they didn't intend—a technique called clickjacking.

Set it to DENY (no framing allowed) or SAMEORIGIN (only your own domain can frame your pages). For eCommerce, SAMEORIGIN is usually the right choice—it prevents external framing while allowing legitimate uses like preview panes in your admin.

X-Content-Type-Options

Set this to nosniff. It prevents the browser from trying to guess (MIME-sniff) the content type of a response. Without it, a browser might interpret a malicious file as executable JavaScript. It's a single header value and there's no reason not to set it.

Referrer-Policy

This controls how much URL information is sent when a user navigates away from your site. For eCommerce, strict-origin-when-cross-origin is the recommended setting. It sends the origin (your domain) to other sites but keeps the full URL path private. This prevents leaking sensitive URL parameters like order IDs or session tokens to third-party services.

Permissions-Policy

Formerly known as Feature-Policy, this header controls which browser features your site can use—camera, microphone, geolocation, payment APIs, and more. Disable anything you don't need. Most eCommerce stores don't need camera or microphone access, so disable them explicitly. This reduces the attack surface if someone manages to inject code into your site.

Strict-Transport-Security (HSTS)

HSTS tells the browser to always use HTTPS when connecting to your site, even if the user types http:// in the address bar. This prevents SSL stripping attacks where an attacker downgrades the connection to HTTP and intercepts data.

Set max-age to at least one year (31536000 seconds) and include includeSubDomains. Once you're confident, submit your domain to the HSTS preload list so browsers enforce HTTPS before even making the first connection.

Cross-Origin Headers (COOP, CORP, COEP)

These three headers work together to enable cross-origin isolation, which protects against speculative execution attacks like Spectre:

• Cross-Origin-Opener-Policy (COOP): Set to same-origin to prevent other windows from getting a reference to your window object
• Cross-Origin-Resource-Policy (CORP): Controls which origins can load your resources. Set to same-origin or cross-origin depending on whether you serve assets to other domains
• Cross-Origin-Embedder-Policy (COEP): Requires all resources to explicitly grant permission to be loaded. Be careful with this one—it can break third-party embeds like YouTube videos or payment widgets

For most eCommerce stores, start with COOP set to same-origin-allow-popups (to support payment pop-ups) and CORP set to cross-origin. Only enable COEP if you specifically need cross-origin isolation and have tested thoroughly.

How to Test Your Headers

Common Mistakes Agencies Make

1. Not Setting Any Headers at All

The most common mistake is simply ignoring security headers entirely. The site "works" without them, so they never get added. This leaves every customer vulnerable to attacks that would be trivially prevented.

2. Setting CSP Too Loosely

A CSP with unsafe-inline and unsafe-eval is barely better than no CSP at all. Yes, removing them might break some third-party scripts. That's a conversation to have, not a reason to leave your customers unprotected.

3. Forgetting to Test After Changes

Adding a strict CSP without testing will break things. Payment widgets, analytics, chat tools—anything loading external resources needs to be in your policy. Always deploy in report-only mode first.

4. Only Securing the Checkout

Security headers should be on every page, not just checkout. Card skimmers can capture data from product pages (via fake "add to cart" overlays) or account pages. Protect the whole site.

5. Not Monitoring CSP Reports

CSP can send violation reports to an endpoint you control. Set up reporting and actually monitor it. This tells you if someone is trying to inject scripts, or if a legitimate service changed its domain and needs updating in your policy.

Implementation Priority

If you're starting from zero, implement in this order: HSTS first (simplest, high impact), then X-Content-Type-Options and X-Frame-Options (one-line headers), then Referrer-Policy and Permissions-Policy, and finally CSP (most complex, biggest security gain). You can get the first four done in an afternoon. CSP will take longer but is worth the investment.