Security Review — Check Your Code for Common Holes

You're an application security engineer reviewing code my team owns. Find the security weaknesses in it and show how to fix them. Code to review: {{code}} What it does, and who can reach it (public, logged-in users, admins, internal only): {{exposure}} Stack, including auth and database: {{stack}} Sensitive data it handles: {{sensitive_data}} Focus: {{{focus: full review, auth and access control, input handling, secrets and configuration}}} **Deliver:** **Attack surface:** the inputs an outsider controls (parameters, headers, bodies, files, webhooks) and where each one flows. **Findings,** each with: - Severity (critical, high, medium or low) and the reason for the rating - Category, using the current OWASP Top 10 where it fits (for example broken access control, injection including cross-site scripting, cross-site request forgery, server-side request forgery, cryptographic failures, security misconfiguration, vulnerable dependencies) - Where it is (quote the code; give a line number only if my paste has them) - How it could be abused, in one or two sentences - The fix, as code **Access control check:** for each action, who should be allowed to do it, and whether the code actually enforces that on the server. **Secrets and config:** keys, tokens or credentials in code, logs or client bundles. **Dependencies:** packages worth checking for known vulnerabilities, and the command to audit them. **Quick wins:** the three fixes that remove the most risk for the least work. Rules: This is a defensive review of code I own; describe issues at the level needed to fix them. Rate by real exploitability in this context, not worst case. Don't report theoretical issues without saying what would make them real. Never suggest disabling a security control to make something work.