Security
How we stay defensible.
A small site with no live server is hard to attack — but the accounts that can change it still need real protection. Here's our posture, and how to tell us if you find something we missed.
Reporting a vulnerability.
If you believe you've found a security vulnerability in this website or any property under
theelixirslab.com, please email
info@theelixirslab.com with
Security in the subject. Encrypted reports preferred but not required.
We respond within 3 business days to acknowledge receipt and within 14 days with a remediation plan or a clarifying question. We don't run a paid bug bounty programme but we credit responsible disclosures publicly with your permission.
A machine-readable contact is also published at
/.well-known/security.txt per
RFC 9116.
In scope
- – The website at
theelixirslab.comand any subdomain we operate - – The newsletter pipeline (subscribe form, archive, unsubscribe flow)
- – Anything in our public source code that's exploitable in production
Out of scope
- – Self-XSS or attacks requiring a malicious browser extension on the victim's device
- – Denial-of-service via traffic flooding (this is a static site behind a CDN — those layers handle it)
- – Issues in third-party services we use (Buttondown, Vercel, Cloudflare, Zoho, GitHub) — please report directly to those providers
Please don't
- – Run automated scanners against the site — we audit manually and they only generate noise
- – Test denial-of-service against real traffic
- – Pivot from any vulnerability you find to access non-public systems
What we already do.
The website
- – Fully static, no live server runtime, no database, no API endpoints under our control
- – Strict HTTP security headers: HSTS preload, CSP, X-Frame-Options DENY, nosniff, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy locking down camera / microphone / geolocation / cohorts
- – No third-party scripts. No analytics, no tag managers, no ads, no embedded social widgets. Everything we ship is first-party
- – Self-hosted fonts — your browser doesn't talk to Google or any other CDN when reading our site
- – No cookies. There are no sessions to hijack because there are no sessions
- – Dependency hygiene: Dependabot enabled, vulnerability advisories patched promptly, transitive issues forced to safe versions via npm overrides
The accounts that can deploy code
Five providers can affect production: our domain registrar, Cloudflare (DNS), Vercel (hosting), GitHub (source), and Buttondown (newsletter). Each one has:
- – Hardware-key two-factor authentication (where supported) or strong TOTP 2FA where it isn't
- – A unique password in a managed vault, never reused
- – Recovery codes printed and stored physically, not in the password manager
- – Account email at our own domain — a breach of personal email can't pivot to company infrastructure
Email anti-spoofing
Mail sent from theelixirslab.com is authenticated via SPF, DKIM, and DMARC.
Receivers can verify that any email claiming to come from us actually did. Unsigned mail
is quarantined; we'll move to a strict reject policy after monitoring confirms legitimate
senders pass.
Subscriber data
Stored at Buttondown under their security posture (managed Postgres on AWS, encrypted at rest, SOC 2 in progress). We hold a monthly offline CSV export as a backup against account loss. We never share, sell, or hand subscriber emails to advertisers. Unsubscribing deletes the record completely.
How we review.
We re-read our security policy quarterly and audit the accounts above each time. The operational checklist lives in SECURITY.md in our repository (private; access on request to clients with active engagements).
Last reviewed: 2026-05-09.