Why we built a static site: security-first web design for small firms
When we sat down to build ravenridgelabs.com, we started with the same question we ask clients: what’s the smallest attack surface that still does the job?
A promotional site and a blog don’t need a database, an admin login, or a plugin ecosystem. Yet those three things account for a large share of website compromises. Outdated plugins, credential stuffing against /wp-admin, and unpatched PHP are perennial entries in incident reports.
So we went static. The pages are HTML generated from Markdown by Astro, and the plan is to serve them from Cloudflare’s edge. There is no origin server for us to patch and no login page to brute-force. Nothing in this repository runs application code when someone loads a page.
We then tightened the defaults the site is built to ship with:
- HTTPS everywhere, with HSTS on the responses.
- A strict Content Security Policy with no inline scripts or styles.
- DNSSEC and CAA records, written down for the domain cutover and not switched on from this repository.
- Email-authentication records that tell the world this domain does not send mail, until a mailbox exists.
- A slot for cookieless analytics that stays empty until we choose to turn it on.
Every change goes through a reviewed pull request, and dependencies are pinned and monitored.
The pages in this repository are already static. Pointing the domain at them, including DNSSEC, is a separate step. The result we want is fast, cheap to run, and boring in the best way. If you’re a small firm weighing a CMS, ask what you actually need to change, and how often. You may find, as we did, that a static site is the most secure feature you can ship.