securitylisted

# Security Security review is not a checklist to tick — it's a way of thinking about trust. For every piece of code, ask: what can an attacker control here, and what can they make the system do with it? ## Threat modeling first Before reviewing specific code, understand the threat surface: 1. **What are the trust boundaries?** Where does untrusted data enter the system? (HTTP requests, file uploads, message queue messages, webhooks, config files loaded from disk) 2. **What are the high-value targets?** (Authentication tokens, PII, financial data, admin functions, ability to execute code) 3. **Who are the threat actors?** Unauthenticated external users, authenticated-but-low-privilege users, internal users with legitimate access, compromised third-party services 4. **What's the worst case?** Data exfiltration, privilege escalation, remote code execution, denial of service, data corruption Use STRIDE to check you haven't missed a category: - **S**poofing — can an attacker impersonate another user or system? - **T**ampering — can an attacker modify data in transit or at rest? - **R**epudiation — can an attacker perform actions that can't be traced back to them? - **I**nformation Disclosure — can an attacker read data they shouldn't? - **D**enial of Service — can an attacker degrade or disable the service? - **E**levation of Privilege — can an attacker gain permissions they shouldn't have? ## Input validation and injection **Never trust external input.** Anything that arr