A compromised website does more than disrupt operations. It damages the brand trust you’ve spent years building. Most breaches don’t happen through sophisticated zero-day exploits. They happen because someone skipped a basic control that wasn’t exciting enough to prioritize.
Security isn’t a feature you bolt on at the end of a project. It’s a set of deliberate decisions made at every layer of the stack.
HTTPS Is the Floor, Not the Ceiling
Every site should serve exclusively over HTTPS. That’s table stakes in 2025: browsers flag plain HTTP sites as “Not Secure,” and search engines deprioritize them. But HTTPS alone doesn’t mean you’re done.
HTTP Strict Transport Security (HSTS) tells browsers to only ever connect to your domain over HTTPS, even if a user types the bare domain or clicks an http:// link. Without it, there’s a narrow window for downgrade attacks on first contact. Set max-age to at least one year, and add includeSubDomains if your subdomains are also HTTPS-ready.
TLS version and cipher suites matter too. TLS 1.0 and 1.1 are deprecated. If your host or CDN still supports them, turn them off. Most managed platforms (Cloudflare, Fastly, Netlify, Vercel) handle this by default, but verify rather than assume. For a clear walkthrough of how HTTPS, SSL, and TLS relate to each other, HTTPS, SSL and TLS Explained is worth reading before you audit your configuration.
Security Headers: Small Config, Real Impact
Security headers are HTTP response headers that tell the browser how to behave. They’re configured in your server, CDN edge, or framework adapter: a handful of lines that eliminate whole categories of attack.
The ones that matter most for brand sites:
Content Security Policy (CSP)
CSP defines what sources of scripts, styles, fonts, and media the browser is allowed to load. A strict CSP prevents cross-site scripting (XSS) attacks from injecting malicious scripts even if an attacker finds an injection point. Start with default-src 'self' and add exceptions only for sources you explicitly trust: your analytics provider, your font CDN, your video embed.
CSP has a learning curve. Use Content-Security-Policy-Report-Only mode first to catch violations in production without blocking anything. Iterate until the report noise is zero, then switch to enforced mode.
X-Frame-Options and frame-ancestors
These headers prevent your site from being loaded inside an iframe on another domain, which is the mechanism behind clickjacking attacks. X-Frame-Options: DENY is the blunt version. The CSP frame-ancestors directive gives you more granular control if you legitimately embed your own pages.
Permissions-Policy
Formerly called Feature-Policy. It lets you disable browser features your site doesn’t need: camera, microphone, geolocation, payment APIs. If a third-party script on your page tries to access the camera and your policy disables it, the request is blocked regardless of what the script does.
Referrer-Policy and X-Content-Type-Options
Referrer-Policy: strict-origin-when-cross-origin limits what URL data leaks to third-party domains in the Referer header. X-Content-Type-Options: nosniff stops browsers from MIME-sniffing responses, a small but meaningful guard against certain content-injection attacks.
A score of A+ on securityheaders.com doesn’t mean your site is unbreachable. It means you’ve removed a predictable class of low-effort attacks from the table.
For a deeper walkthrough of each directive and how to build out a realistic content security policy, Security Headers and Content Security Policy covers the full set.
Dependency and Supply-Chain Hygiene
The majority of code running on a modern website wasn’t written by the team that built it. npm packages, CMS plugins, analytics scripts, and chat widgets are each a vector. Supply-chain attacks have hit some of the most widely-used packages in the ecosystem.
Keep dependencies updated. This is the most boring and most important advice in software. Automated tools like Dependabot or Renovate create pull requests when new versions are available. Review and merge them on a cadence: weekly for security patches, monthly for minor bumps. Pinned-forever lockfiles accumulate unpaid risk.
Audit transitive dependencies. npm audit (or pnpm audit) surfaces known vulnerabilities in your dependency tree, including packages you didn’t install directly. Run it in CI so a high-severity advisory blocks a deploy before it ships.
Subresource Integrity (SRI). If you load any script or stylesheet from an external CDN (a font, a library, an analytics snippet), add an integrity attribute with the file’s hash. If the CDN serves a tampered file, the browser refuses to execute it.
Third-party scripts deserve skepticism. A tag manager that lets anyone on the marketing team add scripts to the site is a wide-open supply-chain surface. Every script added should be reviewed. Chat widgets, A/B testing tools, and affiliate trackers have all been the entry point for real attacks.
This is closely related to performance hygiene: undisciplined third-party scripts are also the most common cause of Core Web Vitals degradation. See Core Web Vitals in 2026: A Field Guide for Brands for the overlap.
Form and Spam Protection
Contact forms, newsletter signups, and comment fields are all surfaces for abuse and injection. Basic protections are not complicated to implement.
CAPTCHA and bot challenges. Google reCAPTCHA v3, hCaptcha, and Cloudflare Turnstile all offer invisible or low-friction bot filtering. Turnstile in particular has no friction for real users and works well on marketing sites. Pick one and apply it to any form that submits data externally.
Server-side validation. Never trust client-side validation alone. Anything submitted to a backend endpoint should be validated and sanitized on the server: field types, lengths, and allowed characters. If you’re building forms for real brand sites, see Designing Forms People Actually Complete for the UX side of that same work.
Rate limiting. A contact form without rate limiting can be used as an email relay, with your sending infrastructure spamming thousands of addresses per hour. Most API gateways and serverless platforms let you add rate limits per IP or session at the edge.
Honeypot fields. A hidden form field that legitimate users never fill in but bots often do. Simple, zero-dependency, and it catches a meaningful percentage of automated spam without any friction to real users.
CMS Hardening
If your site is backed by a CMS, headless or otherwise, the admin interface is a high-value target. The login page for WordPress, Contentful, Sanity, or any self-hosted system gets probed constantly.
Change default admin URLs. WordPress’s /wp-admin is hit by automated scanners millions of times a day. Moving it to a non-standard path reduces noise dramatically. Not a substitute for strong credentials, but it cuts the attack surface.
Enforce strong credentials and MFA. No shared passwords. No reused passwords. Mandatory multi-factor authentication for all admin accounts. This single control stops the majority of credential-stuffing attacks cold. For background on how authentication mechanisms work at the protocol level, Web Authentication Basics covers the concepts that inform these decisions.
Principle of least privilege. Give users the minimum role needed to do their job. A content editor shouldn’t have plugin-install permissions. A developer shouldn’t have access to billing. Audit roles quarterly and remove accounts for people who no longer need access.
Keep the CMS and plugins updated. CMS vulnerabilities are among the most actively exploited on the web. Unpatched WordPress plugins account for a substantial percentage of site compromises every year. Treat CMS updates with the same urgency as dependency updates. Don’t let them age.
For teams evaluating which CMS to build on, Choosing a Headless CMS Without Regret covers the tradeoffs in depth, including how the architecture choice affects your security surface.
Backups: The Recovery Layer
Every other control reduces the probability of a breach. Backups reduce the cost. A clean, recent backup means a ransomware event or accidental deletion is an inconvenience rather than a catastrophe.
Automated, offsite backups. Backups stored on the same server as the site can be encrypted or deleted in the same event that compromised the site. Store them somewhere separate: a different cloud account, a different provider. Automate the schedule so it’s not contingent on someone remembering.
Test restoration. A backup you’ve never restored from is a backup you haven’t verified. Run a restoration drill at least annually, ideally to a staging environment, so you can confirm the backup is intact and you know the procedure before you need it under pressure.
Version history for content. For CMS-backed sites, content version history protects against accidental deletion and malicious content changes. Most modern headless platforms offer this by default; make sure it’s enabled and the retention window is adequate.
How Strynal Approaches Security
When Strynal builds websites and applications, security decisions are part of the architecture conversation, not a post-launch audit. The choice of rendering strategy, the CMS, the deployment target, and the third-party integrations all carry security implications. We scope them deliberately.
The sites we build at Strynal default to static or edge-rendered output where possible, which reduces attack surface by eliminating server-side execution paths that don’t need to exist. Headers are configured at the edge. Dependencies go into CI audit pipelines. Forms use server-side validation before anything touches a database or email system.
Security isn’t something we add when a client asks. It’s the baseline we hold ourselves to because the brand on the domain is what’s at stake.
If you’re assessing the security posture of an existing site or planning a build from scratch, get in touch. We’re glad to talk through where the gaps usually are and what a properly hardened setup looks like for your stack.