Security posture

• No database

  Content is static, typed data checked into the repo. There's no user datastore to breach, because there isn't one.

• Secrets never committed

  Real secrets this site has — the Mailgun API key and the Turnstile secret key — are set via Cloudflare’s encrypted secret store, never in source control or a committed environment file.

• Contact form abuse protection

  Cloudflare Turnstile blocks automated submissions, and a 2-messages-per-4-hours cap is enforced both client-side and by IP — the IP itself is hashed before use and never stored as plain text.

• Minimal, deliberate dependencies

  A native-first policy means most features use browser or framework primitives instead of a package. Fewer dependencies is a smaller supply-chain surface to audit.

• Security headers on every response

  Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and a restrictive Permissions-Policy, applied via a Cloudflare header rule and a SvelteKit hook so both static and dynamic routes are covered.

• Strict TypeScript

  strict: true, no any, across the entire codebase — most type errors are caught before deploy.

• Cloudflare's edge network

  TLS, DDoS mitigation, and edge caching are handled by the hosting platform, not hand-rolled.

An honest tradeoff, not an oversight

The Content-Security-Policy allows 'unsafe-inline' for scripts and styles. That's because a small theme-preference script runs inline in the page head to avoid a flash of the wrong theme, each page injects its own JSON-LD structured data as an inline script, and a couple of components use Svelte's style directive, which renders as an inline style attribute. None of these are user-controlled input, so the practical risk is low, but a strict nonce-based policy would be more defensible — it's the next thing this page will change when it does.

Reporting something

Email kamal@kamal.sh, or see security.txt for the machine-readable version of the same contact.