security-audit

Security audit: verify, validate, harden

You are doing an offensive-minded security review of this repository, then fixing what you find. Work through every section. Do not skip a section because it "looks fine" - say what you checked and what the result was.

Rules that override your instincts

1. Verify, do not pattern-match. Every finding must be demonstrated, not asserted. If you claim a schema accepts a javascript: URL, run it and paste the output. If you claim a header is missing, curl -I the deployed site or read the config. A finding you could not reproduce is not a finding - drop it or label it clearly as unverified.
2. No invented vulnerabilities. A speculative "an attacker could theoretically..." with no path to impact is noise. Rank by reachability first, severity second.
3. This is a static site with no backend, no database, no auth, and no user input. That is a deliberate architectural decision (see docs/adr/). Do not propose adding a backend, a WAF, rate limiting, input sanitisation middleware, or auth. Findings that only apply to a server do not apply here. Say so and move on.
4. Never add a dependency to fix a finding without saying what it is, what it costs, and what the no-dependency alternative was.
5. Never read, echo, print, or cat .env. Not to check it, not to verify a fix. Prove things about it with git check-ignore, ls -l, and git log instead. This repo is demoed on a shared screen.
6. Follow the loop in CLAUDE.md. Anything you change gets an ADR in docs/adr/ first and a test that would fail without the fix.

Threat model - who actually attacks this

Rank findings against these, in order. If a finding does not serve one of them, it is a nice-to-have and should be labelled as such.

• T1 - Credential leak. The Netlify token, in the repo, in git history, in the build output, in CI logs, on a shared screen. This is the one that costs real money and a real account takeover.
• T2 - Supply chain. A malicious or compromised npm package or GitHub Action running with the deploy token in its environment. The deploy step is the crown jewel: it has the token.
• T3 - Content injection. This is a template. Strangers fork it and paste content in from resumes, from LLM output, from a friend. Content is untrusted input to this codebase even though it lives in a .ts file.
• T4 - The visitor's browser. Clickjacking, MIME sniffing, referrer leakage, mixed content, reverse tabnabbing, and whatever a stray injected script would be able to reach.
• T5 - Doxxing the author. A real resume in the repo, a home address in a PDF's metadata, an email harvested from the built page. Low severity for a machine, high for a person.