$ cat posture.conf

Working in cybersecurity means I'm well aware that the moment a site goes live, it's only a matter of time before all types of hats have their eyes on it - malicious, defensive, and curious readers alike. I took this as an opportunity to build the site with security-first thinking while also being transparent about the architectural decisions, trade-offs, and hardening steps that went into it.

This page serves as a look behind the curtain.

## philosophy: subtraction first

"The most secure system is the one that's offline." Along those same lines, the cheapest vulnerability to fix is the component that does not exist.

With that mindset, this site is pre-built as a static website and served from a CDN. There is no database, no server-side rendering, no session handling, and no login system. It accepts zero user input on any endpoint. The only dynamic piece is a single read-only serverless function at /api/cve-feed. It fetches one hard-coded government data source and caches the result. Because it takes no parameters, entire classes of attacks like SSRF are structurally impossible.

Publishing happens through git commits, which also serves as a clean, tamper-evident audit log. If this site is ever defaced, git will show me exactly when it happened and I'll be genuinely fascinated to learn how.

## in your browser

Every response ships a strict Content-Security-Policy with no unsafe-inline allowed. In plain terms, that's a header telling your browser: run code from this site, plus one allowlisted origin for comments. This decision forced some practical compromises. For example, I had to use a simpler syntax highlighter that works with class-based styling instead of a fancier option that relied on inline styles.

I also set strong HSTS, nosniff, frame denial, a locked-down Permissions-Policy, and cross-origin isolation headers, which I'll cover more in-depth in a future blog post.

The security tools on this site run entirely in your browser; nothing you type into them leaves the page. You can verify this yourself in DevTools on the Network tab or in airplane mode.

verify independently: securityheaders.com · Mozilla Observatory

## supply chain

Like every modern website, mine is a thin layer of my code on top of a mountain of other people's code. Pretending otherwise would be the first mistake. So: dependency versions are locked, packages can't run install scripts unless I've explicitly allowlisted them, a bot nags me weekly about updates, and findings I can't fix are documented with a contextual analysis of whether they're actually reachable.

## found something anyway?

Found something? I would genuinely like to know. Machine-readable details are available in /.well-known/security.txt (RFC 9116).

the full build story: "How I secured this site"