# ADR 054: Gitleaks (Secret Scanning)

- HTML version: https://robbiepalmer.me/projects/recipe-site/adrs/058-gitleaks
- Project: Recipe Site (https://robbiepalmer.me/projects/recipe-site.md)
- Status: Accepted
- Date: 2026-07-20
- Inherited from project: personal-site (https://robbiepalmer.me/projects/personal-site/adrs/054-gitleaks.md)

# Additional Context for Recipe Site

The recipe site concentrates the credentials worth stealing: Neon Postgres
connection strings, better-auth secrets, OAuth client secrets (Google/GitHub
login), OpenRouter API keys, and Cloudflare tokens for the Workers. Most of
these are exactly the shapes GitHub's provider-pattern scanning is weakest on —
a Postgres URL with an inline password or a better-auth signing secret has no
vendor-recognisable format, but does trip gitleaks' generic and entropy rules
(see [personal-site ADR 054](/projects/personal-site/adrs/054-gitleaks)).

The financial-risk framing from
[ADR 035 (application security baseline)](/projects/recipe-site/adrs/035-application-security-baseline)
applies directly: a leaked OpenRouter key or database URL converts to
unauthorized usage cost or a data breach of user accounts, so blocking the
commit beats rotating after disclosure.

# Consequences

## Positive

* Database URLs and auth secrets — the credential shapes vendor-pattern
  scanning misses — are checked before a commit exists, on the side of the
  monorepo where they circulate most (local `.dev.vars`, seeded QA scenarios,
  integration-test configs).

## Negative

* Seeded QA fixtures and example configs are the likeliest source of false
  positives; expect the first `.gitleaks.toml` allowlist entries to come from
  the recipe-site test surface.

## Notes for Recipe Site

# Additional Context for Recipe Site

The recipe site concentrates the credentials worth stealing: Neon Postgres
connection strings, better-auth secrets, OAuth client secrets (Google/GitHub
login), OpenRouter API keys, and Cloudflare tokens for the Workers. Most of
these are exactly the shapes GitHub's provider-pattern scanning is weakest on —
a Postgres URL with an inline password or a better-auth signing secret has no
vendor-recognisable format, but does trip gitleaks' generic and entropy rules
(see [personal-site ADR 054](/projects/personal-site/adrs/054-gitleaks)).

The financial-risk framing from
[ADR 035 (application security baseline)](/projects/recipe-site/adrs/035-application-security-baseline)
applies directly: a leaked OpenRouter key or database URL converts to
unauthorized usage cost or a data breach of user accounts, so blocking the
commit beats rotating after disclosure.

# Consequences

## Positive

* Database URLs and auth secrets — the credential shapes vendor-pattern
  scanning misses — are checked before a commit exists, on the side of the
  monorepo where they circulate most (local `.dev.vars`, seeded QA scenarios,
  integration-test configs).

## Negative

* Seeded QA fixtures and example configs are the likeliest source of false
  positives; expect the first `.gitleaks.toml` allowlist entries to come from
  the recipe-site test surface.

---

Markdown index of this site: https://robbiepalmer.me/llms.txt