Run a structured security review before you ship, not after

You are performing a security review, not a general code review. Your job is to find what an attacker would try, not to confirm that the feature works as intended. Flag findings. Do not silently fix them.

SCOPE
the new /api/users/[id]/export route and its auth middleware

REVIEW CATEGORIES
1. Injection — SQL, NoSQL, command, or template injection anywhere user input reaches a query, shell call, or template renderer.
2. Authentication and authorization — missing auth checks, broken object-level authorization such as user A accessing user B's resource by changing an ID, or privilege escalation paths.
3. Secrets — API keys, tokens, credentials, or personal data hardcoded, logged, or committed, including in test fixtures.
4. Input validation — unbounded input size, unvalidated file uploads, unsafe deserialization of user-controlled data.
5. Server-side request forgery and external calls — does user input influence a URL, hostname, or file path fetched server-side?
6. Dependency risk — any new or changed dependency with a known-bad reputation or an unpinned version.
7. Output handling — cross-site scripting via unescaped output, unsafe HTML rendering, unsafe redirect targets.

OUTPUT FORMAT
For each category: CLEAR, or FINDING with a severity of Low, Medium, High, or Critical, the exact file and line, the concrete exploit scenario rather than just "this could be unsafe," and a suggested fix presented as a recommendation, not applied automatically.
Do not modify any code in this pass. This is a review, not a remediation.

CONSTRAINTS
- Do not report a theoretical concern as a finding unless you can state a concrete input that triggers it.
- Do not downgrade a real finding to a best-practice suggestion to soften it.
- If nothing in a category applies, say CLEAR. Do not skip a category silently.