fix-security-vulnerabilities-with-strixlisted

# Fix Strix findings and verify Turn validated Strix findings into minimal, correct fixes — and prove they work by re-scanning. ## 1. Triage Get the findings from wherever the scan ran: - **OSS CLI** — artifacts in `strix_runs/<run-name>/`: - `vulnerabilities/*.md` — one finding per file: description, severity, PoC steps or script, affected code locations, remediation guidance. - `vulnerabilities.json` — the same findings as JSON (ids, severity, CWE/CVE, `code_locations` with `fix_before`/`fix_after` suggestions when available). - **Cloud (app.strix.ai)** — fetch the scan's `vulnerabilities[]` via `GET /api/v1/scans/{scanId}` (or `GET /api/v1/vulnerabilities` org-wide). Each carries `severity, cwe, endpoint, method, impact, technical_analysis, poc_description, poc_script_code` and, for code findings, `code_file`/`code_diff`/`code_before`/`code_after`. See the **managed-pentesting-with-strix** skill for auth. Order work by severity: critical → high → medium → low. Every Strix finding was validated with a working proof-of-concept, so do not dismiss findings as false positives without re-testing the PoC yourself. ## 2. Fix For each finding: 1. Reproduce it with the PoC from the finding file when feasible. 2. Fix the root cause, not the specific payload (e.g. parameterize all queries, don't blocklist one string; enforce authorization in the handler, don't hide the endpoint). 3. Prefer the framework's built-in defense (ORM parameterization, template auto-escaping, CSRF