Топ-10 уязвимостей в коде, которые стоит искать в 2026 году

Большинство взломов по-прежнему начинается с горстки хорошо известных классов ошибок. Фреймворки стали безопаснее, но ошибки переехали: в обработчики API, фоновые задачи, инфраструктурный код и связующий слой между сервисами. Вот список того, что мы проверяем в первую очередь на каждом аудите, вместе с CWE, который вы увидите в отчёте CodeAuditAgent.

1. Нарушение контроля доступа (CWE-639, CWE-862)

Самая частая серьёзная находка с большим отрывом: эндпоинт загружает запись по ID, не проверяя, принадлежит ли она вызывающему. Аутентификация говорит, кто перед вами; авторизация должна выполняться в каждом отдельном запросе.

// Scope every lookup to the owner
const invoice = await db.invoice.findFirst({
  where: { id, userId: session.user.id },
});

2. Инъекции (CWE-89, CWE-78)

SQL, собранный из строк, команды оболочки и выражения в шаблонах всё ещё встречаются повсюду, обычно в том самом запросе, который кто-то написал вручную ради производительности. Параметризуйте запрос или передавайте аргументы массивом; никогда не склеивайте входные данные.

3. Захардкоженные секреты (CWE-798)

API-ключи, закоммиченные в репозиторий, тестовые токены, которые оказались боевыми, приватные ключи в конфигурационных файлах. Перенесите их в переменные окружения или менеджер секретов и ротируйте всё, что когда-либо попадало в коммит: удаление строки не удаляет историю.

4. Подделка серверных запросов, SSRF (CWE-918)

Любую функцию, которая загружает URL, переданный пользователем, например вебхуки, превью ссылок или импорт, можно направить на вашу внутреннюю сеть или эндпоинт метаданных облака. Используйте allowlist хостов, резолвьте и проверяйте IP-адрес, блокируйте приватные диапазоны.

5. Межсайтовый скриптинг, XSS (CWE-79)

Современные фреймворки экранируют данные по умолчанию, поэтому XSS теперь прячется в обходных лазейках: пропсах с сырым HTML, рендерерах markdown и URL в атрибутах href. Санитизируйте HTML проверенной библиотекой и отклоняйте URL вида javascript:.

6. Небезопасная десериализация и eval (CWE-502, CWE-95)

Pickle, YAML load, потоки объектов Java и динамический eval превращают данные в код. Вместо этого используйте безопасные загрузчики и JSON с валидацией по схеме.

7. Слабая криптография (CWE-327, CWE-330)

MD5 или SHA-1 для паролей, статические IV, Math.random() для токенов. Используйте хеш-функцию, созданную специально для паролей (Argon2id, bcrypt, scrypt), и криптографически стойкий источник случайности.

8. Открытые редиректы (CWE-601)

Параметр next или returnTo, принимающий любой URL, превращает ваш домен в доверенную стартовую площадку для фишинга. Принимайте только относительные пути в пределах того же origin.

9. Отсутствие rate limiting (CWE-307, CWE-770)

Вход, сброс пароля, OTP и любой эндпоинт, который стоит вам денег (email, SMS, вызовы AI), нуждаются в лимитах на пользователя и на IP. Без них брутфорс и атаки, раздувающие ваши счета, тривиальны.

10. Небезопасная конфигурация (CWE-16)

CORS с wildcard и credentials, режим отладки в продакшене, подробные стектрейсы, слишком разрешительные политики бакетов. На код-ревью это редко похоже на баги, потому что живёт в конфигурации, и именно поэтому её нужно ревьюить как код.

Как пользоваться этим списком

• Проверяйте классы с 1 по 3 в каждом пул-реквесте: у них самое большое влияние, и их проще всего пропустить.
• Относитесь к конфигурации инфраструктуры и CI как к коду, который проходит ревью.
• Фиксируйте CWE для каждой находки, чтобы отслеживать исправления и измерять тренды.