August 12, 2025

From Zero to A+, Launching and Securing kevhq.com

I bought this domain yesterday and I’ve just finished taking kevhq.com live on S3 + CloudFront today. I’ve deployed a few static sites like this before, so I thought I’d share my security and performance checklist for “go live” day. This isn’t a how-to, more of a quick tour and a few “why even bother?” answers. All of this took just a couple of hours, and the end result is:

• A secure, lightning-fast static site
• A+ on SecurityHeaders and SSLLabs.
• Extra security hardening

No nonsense. Vamos.

Hosting & Delivery

• S3 buckets: one main to host and one www one to redirect to root. No servers means less attack surface and fast responses.
• CloudFront with OAI for speed while keeping the S3 bucket locked from public access.
• Redirects at the edge; “pretty URLs” via viewer-request rewrites to index.html.

TLS & Certificates

• ACM ECDSA P-256: faster and more secure than the default RSA 2048.
• CloudFront TLS policy: TLSv1.2_2021. AWS recently added TLSv1.3_2025, which is technically more secure (TLS 1.3 only) but oddly caps your SSL Labs score at A. I suspect this is because dropping TLS 1.2 hurts compatibility with slightly older browsers, which affects SSL Labs scoring. Switching to a very slightly less secure TLS policy got me back to A+. Go figure.

Additional Security Hardening

• HSTS (preload): max-age=31536000; includeSubDomains; preload. HSTS header including subdomains is just great. Signals that I will always run my domain with HTTPS. No reason not to have this.
  Also submitted to the preload list. Modern browsers already warn about non-HTTPS even on first visit, so the extra gain from preload is small, but knowing my domain name is buried somewhere deep in every browser’s source code gives me a silly little ego boost.
• CAA DNS record: Restricts which certificate authorities can issue for your domain. The attack vector here is small but has happened. My CAA record just says only Amazon can issue for kevhq.com. Is just a 2 minute job so no excuses really.
• DNSSEC: Your DNS queries are probably sent over plain text meaning everyone from the hotel staff, the shady guy in the cafe to your ISP knows what sites you are visiting. DNSSEC itself doesn’t solve this but it does prevent one of those shady actors intercepting your DNS request and sending you to a malicious site via a man in the middle attack. DNSSEC is about authenticity, not privacy, as your resolver can still see queries. Set-and-forget in Route53. Is a one time setup and a very quick win for administrators.
  As an aside if you want DNS privacy, please go to the effort of making sure you are using DoH or DoT. Tho even then, your DNS resolver knows (and is probably selling) your internet browsing habits. ODNS is a proposed solution in development for this but no real support yet. Fingers crossed.
• SVCB/HTTPS records with ALPN: Only learned about these recently. Let supporting browsers know up-front that the site supports HTTP/2 and HTTP/3 so it can skip the HTTP/1.1 handshake and connect faster. Tiny speed win, permanent benefit.
• Content-Security-Policy: CSP locks down where the browser can load resources from. For such a simple site, locking everything down is the only good default. This is a huge practical security win. Can always loosen later if needed.

Content-Security-Policy: default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; font-src 'self'; script-src 'self'; connect-src 'self'; base-uri 'self'; frame-ancestors 'none';

• Permissions Policy: Explicitly block unneeded browser APIs like geolocation, camera, or microphone. Default-deny is the best default for almost every site.

Permissions-Policy: geolocation=(), microphone=(), camera=(), payment=()

• Other good defaults:
  • Referrer-Policy: strict-origin-when-cross-origin
  • X-Content-Type-Options: nosniff
  • X-Frame-Options: DENY
  • X-XSS-Protection: 1; mode=block

All these headers can be set in CloudFront. I let CloudFront override origin headers, since my S3 bucket doesn’t set them.

Conclusion

In a couple of hours, can go from a freshly registered domain to a solid security baseline. For a static site, the benefit maybe minimal but this is my default. Anything less, and I wouldn’t respect myself.

My next todo item is setup my email domain so I guess the next post on will proberbly be on Email security.