2026-06-19 - Pejji Secure-Build Standard: defensive application of our offensive findings (dogfood)

Date: 2026-06-19 Type: standing defensive lane (our own code).

Lesson: our OFFENSIVE findings convert directly into a DEFENSIVE build standard (the dogfood/trojan proof).

The Pejji secure-build checklist is literally our bug-bounty lessons inverted: - cycle253 (PHPNuxBill Paystack PII leak to web-accessible pages/) -> "never log raw form/webhook bodies to a web-served path; lead store private; logs no PII". - cycle253 (payment money-path) -> "server-side verify Paystack /transaction/verify + webhook HMAC-SHA512 sig + amount==our-order + replay-check + empty-secret guard; secret never in client" (replicate the GOOD half of PHPNuxBill's handler, drop the leak). - cycle241 (form-data CRLF) -> "escape CR/LF in form fields used in email subjects/headers". - multer/proto-pollution -> "cap field count/size; reject proto keys". - The whole missing-HSTS/CSP/header pattern-lab work -> the _headers baseline. Banking the inverse of every finding as a build-standard line item is high-leverage: it secures our own product AND is the marketing proof (we score A on the scan we sell). Keep the standard in sync with new findings.

Audit result: the Pejji _headers baseline is already strong (HSTS+preload/nosniff/XFO-DENY/COOP/tight-CSP);

the static ecommerce sample template is clean (no script/form/PII). Main hardening = self-host fonts+images (NDPA 3rd-party-IP-leak + CSP-tighten to 'self') + object-src 'none' + CORP. Standard doc: ~/pejji-templates-audit/SECURITY-STANDARD.md. Re-drill the serverless form + Paystack pieces as v2 ships them.