Evidence · 03
How do you think about security?
As a zero-trust audit, then remediation mapped to specific threats — not a checklist of buzzwords bolted on afterward.
| Control | Threat mitigated | Implementation | Status |
|---|---|---|---|
| JWT denylist | Stolen or leaked token reused after logout | Revoked tokens tracked server-side and checked on every authenticated request | Enforced |
| bcrypt hashing | Credential or OTP database leak | Passwords and OTPs bcrypt-hashed before storage — never stored in plaintext | Enforced |
| IDOR / authz guards | Cross-account access to another user's data | Explicit ownership checks on every resource route, verified in a zero-trust audit | Fixed |
| OTP rate limiting | Brute-force OTP guessing | 5 attempts per 30 minutes, then locked | Capped |
| PII masking | Contact leakage before a tenant pays | Owner and tenant phone numbers stay masked until a paid unlock clears | Enforced |
| Stored XSS remediation | Malicious script injected via listing content | Input sanitized and output-encoded; found and fixed during a zero-trust security audit | Fixed |
| Money / PII audit logging | Undetected fraud or data misuse | Every payment event and PII access is written to an audit log | Enforced |
| Prod fail-fast config | Silent misconfiguration reaching production | App refuses to boot in production if dev-only settings or secrets are detected | Enforced |
| Webhook signature verification | Spoofed WhatsApp/Meta webhook payloads | Every inbound webhook is signature-checked before it's processed | Enforced |
Philosophy
Assume the request is hostile, then prove it isn't
Every control above exists because a specific attack path was named first: token replay, credential leak, cross-account access, brute force, contact scraping, script injection, silent misconfiguration, forged webhooks. None of them were added speculatively — each maps to a threat identified in a zero-trust security audit and closed with a verifiable fix, not a policy document.