Security headers beginners should know (high-level)

Short answer: Security headers are server responses that steer browsers toward safer behaviour—reducing some XSS, clickjacking, and MIME sniffing risks when set sensibly.

They are not a substitute for secure code, but they are a cost-effective layer many NZ SMEs can enable via hosting, CDN, or a careful server config.

Headers owners hear about most

• Content-Security-Policy (CSP): limits where scripts and assets may load—powerful but can break sites if too strict without testing.
• Strict-Transport-Security (HSTS): tells browsers to prefer HTTPS—ensure HTTPS works everywhere first.
• X-Frame-Options / frame-ancestors: reduces clickjacking by controlling iframe embedding.

Practical approach for SMEs

Start with hosting defaults and HTTPS everywhere. Add CSP in report-only mode if your stack supports it, read violations, then tighten gradually. Avoid copy-pasting mega-policies from blogs without testing forms, payment embeds, and tag managers.

How this ties to SEO and trust

Browsers (and users) favour stable, secure experiences. Mixed-content warnings and intermittent “not secure” states hurt confidence even when rankings are not directly penalised.

Frequently asked questions