field guide

Website Security & Hardening

What's actually running on this site's connection, headers, and DNS — not just a writeup of it, a real worked example. Every control below is live on this domain and independently checkable with a single command, and most of them are inexpensive enough to add to nearly any site regardless of host or stack — so this doubles as a practical reference if you're hardening one of your own.

How to read this: each item pairs the plain-English reason with either the live value or a copy-pasteable command to check it yourself. If something here doesn't match what the live site actually sends, that's a bug in the site, not in this page — see vulnerability disclosure below.

Transport & DNS

HSTS preload

Forces HTTPS for two years, including every subdomain, and is submitted to browsers' built-in HSTS preload list — so even the very first request a browser ever makes to this domain never gets a chance to go out over plaintext HTTP.

verify
curl -sI https://spiritualmachines.ca | grep -i strict-transport-security
> strict-transport-security: max-age=63072000; includeSubDomains; preload
DNSSEC

The zone is signed and a DS record is published at the registrar, so a resolver that checks DNSSEC can cryptographically verify these DNS answers weren't forged or tampered with in transit (cache poisoning, off-path spoofing).

verify
dig DNSKEY spiritualmachines.ca +short
> 256 3 13 ... (zone-signing key)
> 257 3 13 ... (key-signing key, matches the DS record at the registrar)
CAA records

Restrict which Certificate Authorities are allowed to issue a TLS certificate for this domain at all — anyone else's issuance request gets rejected before a certificate is ever minted, regardless of any other check they might pass.

verify
dig CAA spiritualmachines.ca +short
> 0 issue "letsencrypt.org"
> 0 issue "pki.goog; cansignhttpexchanges=yes"
> 0 issue "sectigo.com"
> 0 issue "ssl.com"
> 0 issue "comodoca.com"
> 0 issue "digicert.com; cansignhttpexchanges=yes"
> (same six repeated under issuewild)
Certificate Transparency monitoring

An alert fires the moment any new certificate is logged for this domain in a public CT log — whether it was actually requested by us or not — so a mis-issued or fraudulent certificate doesn't sit undetected.

verify
Any public CT log search, e.g. crt.sh/?q=spiritualmachines.ca
Post-quantum-hybrid TLS

The handshake already negotiates a hybrid key exchange resistant to a future "harvest now, decrypt later" quantum attack — nothing to configure on this end, it's the ambient default Cloudflare's edge negotiates on the connection this page loaded over.

verify
openssl s_client -connect spiritualmachines.ca:443 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep "Negotiated TLS1.3 group"
> Negotiated TLS1.3 group: X25519MLKEM768

HTTP response headers

Content-Security-Policy

Default-deny baseline (default-src 'none') with every allowance listed explicitly. The two inline scripts that exist are pinned by their exact SHA-256 hash rather than allowed via a blanket 'unsafe-inline', so injecting a third script — even through a real XSS bug elsewhere on the page — has nothing it's permitted to execute.

verify
curl -sI https://spiritualmachines.ca | grep -i content-security-policy
> default-src 'none'; script-src 'self' 'sha256-xzwFeIy0I7FG1WPXwUQiT1eP1zeSTVFTkdJRTsGYcvQ=' 'sha256-HzxkWWmMtwS0Td6uN6GQGLSi5a/vWOLX/TC/ZemnYG8=' static.cloudflareinsights.com; style-src 'self' 'unsafe-inline'; img-src 'self'; font-src 'self' data:; connect-src 'self'; frame-src 'none'; frame-ancestors 'none'; object-src 'none'; base-uri 'self'; form-action 'self'; require-trusted-types-for 'script'; trusted-types sm-components; upgrade-insecure-requests
Cross-origin isolation triad

COOP, COEP, and CORP together stop this page from being pulled into another origin's process, and stop it from sharing a process or memory space with a cross-origin document that tries to embed it.

verify
curl -sI https://spiritualmachines.ca | grep -i cross-origin
> cross-origin-opener-policy: same-origin
> cross-origin-embedder-policy: require-corp
> cross-origin-resource-policy: same-origin
Clickjacking, MIME-sniffing & referrer leakage

X-Frame-Options: DENY stops this site being framed by another page at all. X-Content-Type-Options: nosniff stops a browser reinterpreting a response as a different content type than it was served as. Referrer-Policy: strict-origin-when-cross-origin limits what leaks in the Referer header on outbound links.

verify
curl -sI https://spiritualmachines.ca | grep -iE "x-frame|x-content-type|referrer-policy"
Permissions-Policy

A deny-list turning off roughly 19 browser APIs — camera, microphone, geolocation, USB, payment, screen-wake-lock, and more — that this site has no legitimate use for, so even a future bug in the code can't request them.

verify
curl -sI https://spiritualmachines.ca | grep -i permissions-policy
> accelerometer=(), autoplay=(), camera=(), display-capture=(), encrypted-media=(), fullscreen=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), xr-spatial-tracking=()

Client-side script integrity

Trusted Types

A single declared policy (sm-components) is the only code path allowed to hand the browser a string it will treat as HTML. Every component on this site routes its innerHTML writes through that one function instead of assigning a raw string directly, so a script-injection attempt that doesn't go through the declared policy is rejected by the browser itself — not by application logic that could have a bug in it. Enforced today on Chromium-based browsers; Firefox and Safari fall through to a harmless no-op rather than breaking.

verify
Open DevTools console on this site in a Chromium-based browser (Chrome, Edge, Brave):
trustedTypes.getPolicyNames()
> ["sm-components"]

Architecture

Static site, one isolated Worker

There is no database, no admin login, and no server-rendered app anywhere on this site. The one genuinely dynamic piece — the contact form's relay to email — is a small, single-purpose Cloudflare Worker with no shared state with anything else. Most of what "the website got hacked" actually means in practice — a stolen database, a defaced CMS, leaked admin credentials — has no attack surface here to begin with.

Anything dynamic added later stays isolated

A forum, a store, or running someone else's code live in the terminal are all explicitly scoped, if they're ever built, as their own subdomain, process, and database from day one — never folded into this codebase — so a vulnerability in one can't reach the others.

Vulnerability disclosure & encrypted contact

security.txt (RFC 9116)

A machine-readable disclosure contact at a standard, predictable path, so a researcher — or a scanner — doesn't have to hunt for how to report something.

verify
curl -s https://spiritualmachines.ca/.well-known/security.txt
> Contact: mailto:info@spiritualmachines.ca
> Encryption: https://spiritualmachines.ca/.well-known/pgp-key.txt
> Expires: 2027-07-22T00:00:00.000Z
> Preferred-Languages: en
> Canonical: https://spiritualmachines.ca/.well-known/security.txt
PGP key for encrypted reports

Ed25519 (sign/certify) plus Cv25519 (encrypt), published at /.well-known/pgp-key.txt and linked from security.txt's Encryption: field, so a sensitive report never has to sit in plaintext in a mail server's logs. The full key block and fingerprint are also shown in plain text on the contact page — verify the fingerprint out-of-band before trusting it, standard PGP practice.

No public mailto:

The contact form posts to a Worker endpoint that relays server-side via Resend, instead of printing a scrapable mailto: link on the page, and includes a honeypot field to filter obvious bots — so an address-harvesting crawler doesn't find a free inbox to spam the moment it indexes the page.

Anti-abuse

Bot Fight Mode

Enabled at Cloudflare's edge — challenges or blocks automated traffic before it ever reaches the site, ahead of anything the site's own code has to handle.