fix(security): resolve PR #1703 review findings (CSRF FPs, secret fixture)

[akansnoro]

Follow-up to #1703, which is already merged. This clears the two review
threads that were left unresolved there.

Semgrep: subtrackr.csrf.state-changing-route-without-csrf (x2)

The rule fired on these two lines in backend/server/createApiServer.ts:

app.post('/api/v1/stripe/billing/webhook', express.raw({ type: '*/*', limit: MAX_JSON_BODY }));
app.post('/api/v1/paddle/webhook', express.raw({ type: '*/*', limit: MAX_JSON_BODY }));

These are false positives. Both lines install a body parser only — they
declare no handler and change no state. The rule matches $ROUTER.post($PATH, $HANDLER) and excepts only a middleware literally named csrfProtection,
requireAuth or verifyWebhookSignature; it cannot follow the call into
createStripeBillingRouter / createPaddleRouter in other files.

The routes are genuinely protected, and they fail closed:

Condition	Response
Signing secret unconfigured (verifier === null)	503
HMAC over raw bytes does not match	401
Already-delivered event id	200 { duplicate: true }, never dispatched

The digest is compared with crypto.timingSafeEqual inside a 300 s replay
window (StripeWebhookVerifier.verify / PaddleWebhookVerifier.verify).

Why this is not fixed by adding middleware to the route

The tempting fix — running verify() again at the app level — is a silent
production regression. verify() calls remember(eventId) on success, so a
second call within the same request returns fresh: false, and the router
then answers 200 { duplicate: true } without ever dispatching the event.
Every Stripe/Paddle subscription lifecycle update would be dropped.

So this lands as a documented suppression (inline nosemgrep plus an entry in
.semgrep/semgrep-suppressions.yml with a 6-month expiry), with the
double-verification trap written into the code comment so the next reviewer
does not "fix" it the obvious wrong way.

GitGuardian: hardcoded Zapier webhook URL

outboundUrlGuard.test.ts asserted on:

validateOutboundUrl('https://hooks.zapier.com/hooks/catch/1/2/')

A fixture, not a secret — but the /hooks/catch/<n>/<n>/ path shape is
indistinguishable from a live hook URL, so it raised a false incident. Replaced
with a non-/hooks/catch/ path on the same host. The assertion only needs
"public host over https", and realistic Zapier-hostname coverage is kept.

Verification

• node --experimental-strip-types --check passes on both touched TS files.
• The nosemgrep justification gate from security-scan.yml was reproduced
  locally and passes (every suppression line carries a reason:).
• npm run lint, npm run typecheck and the Jest suites were not run —
  node_modules is not installed in this environment. CI will cover those.