Code review с фокусом на безопасность

Действуй как security-инженер. Ревью кода: {{diff}}.

Подход: идём по OWASP Top 10 + специфика проекта.

1. Injection (SQL, command, LDAP, ORM)

• Все SQL-запросы используют параметризацию?
• Никаких string-concat для построения query?
• Команды shell не строятся через template literals из user input?
• ORM не используется в небезопасных режимах (raw queries)?

2. Broken Authentication

• Сессии: HttpOnly, Secure, SameSite cookies?
• Пароли: bcrypt/argon2, никаких MD5/SHA1?
• JWT: подпись проверяется? exp проверяется?
• Rate limiting на login / signup / password reset?

3. Sensitive Data Exposure

• Секреты в коде? (искать API_KEY, SECRET, TOKEN, PRIVATE)
• Логирование не включает PII / токены / пароли?
• HTTPS форсится? HSTS?
• Чувствительные поля исключены из логов / ответов API?

4. XML External Entities (XXE)

• Парсер XML отключает внешние entities?

5. Broken Access Control

• Каждый защищённый endpoint проверяет permission?
• IDOR (Insecure Direct Object Reference) — пользователь не может изменить ID и получить чужие данные?
• Server-side проверка прав, а не клиентская?
• Admin-функции имеют отдельную проверку?

6. Security Misconfiguration

• Debug режим выключен в продакшене?
• CORS настроен restrictive (не *)?
• Security headers (CSP, X-Frame-Options, X-Content-Type-Options)?
• Default-creds для admin-панелей?

7. XSS

• User input экранируется при выводе?
• dangerouslySetInnerHTML / innerHTML — обоснован?
• Content Security Policy с restrictive script-src?

8. Insecure Deserialization

• Не pickle от user input?
• JSON.parse без reviver опасным?

9. Using Components with Known Vulns

• npm audit чистый?
• Зависимости актуальны?
• Отсутствуют пакеты с известными CVE?

10. Insufficient Logging

• Security события логируются (login fail, perm denied, suspicious)?
• Логи не утекают чувствительными данными?

11. Специфика проекта

Дополнительно проверь:

• Webhook'и: подпись валидируется?
• File upload: тип / размер / путь?
• API: idempotency, rate limits, версионирование?
• Прав доступа на запись в storage / DB?

Формат отчёта

## Критические (CVE-уровень)
| Файл:строка | Проблема | Атака | Фикс |

## Серьёзные
...

## Минорные
...

## Что выглядит хорошо
- ...

Принципы

• Не "может быть уязвимостью" — конкретная атака с шагами
• Не предлагай "добавить sanitization" — укажи библиотеку и место
• Если не уверен — отметь как "проверить вручную"
• Не пиши "use HTTPS" если уже HTTPS