Контрольный список безопасности Claude Code для быстрой spot‑проверки веб‑приложений

Что такое лёгкая проверка безопасности

Лёгкая проверка безопасности — это быстрый обзор (обычно 30–60 минут), цель которого — найти очевидные, высокоэффективные проблемы до релиза. Это не полный аудит. Представьте это как обход безопасности: вы просматриваете те пути, которые чаще всего дают сбои в реальных приложениях, и ищете доказательства, а не догадки.

Этот контрольный список Claude Code фокусируется на областях, которые чаще всего ломаются в повседневных веб‑приложениях:

• Предположения об аутентификации (как вы узнаёте, кто пользователь)
• Пробелы в авторизации (что пользователю разрешено делать)
• Валидация входных данных
• Обращение с секретами
• Распространённые поверхности для инъекций (SQL, выполнение команд, рендеринг шаблонов, редиректы, загрузки)

Он не пытается доказать отсутствие багов, моделировать сложных угрозщиков или заменить тесты на проникновение.

«Конкретные находки» означают, что каждая запись содержит доказательства, по которым разработчик сможет действовать немедленно. Для каждой находки зафиксируйте:

• Точные файл(ы) и имя функции/обработчика
• Рискованное поведение в одном предложении
• Минимальные шаги для воспроизведения (запрос, полезная нагрузка или путь клика)
• Почему это важно (влияние) и кто может это вызвать
• Направление безопасного исправления (не полный рефакторинг)

ИИ — помощник, а не авторитет. Используйте его для поиска, суммаризации и предложений тестов. Затем проверяйте, читая код и, по возможности, воспроизводя запросы. Если модель не может указать конкретные места и шаги, относитесь к утверждению как к неподтверждённому.

Установите область проверки за 10 минут

Быстрая проверка работает, только если вы сужаете цель. Прежде чем попросить Claude Code что‑то просмотреть, решите, что вы пытаетесь доказать сегодня и что не проверяете.

Начните с 1–3 реальных сценариев пользователя, где ошибки стоят денег, раскрывают данные или дают власть. Хорошие кандидаты: вход в систему, сброс пароля, оформление заказа и экраны редактирования администратора.

Далее назовите активы, которые нужно защитить. Будьте конкретны: учётные записи пользователей, операции с платежами, персональные данные, операции только для админов.

Затем запишите ваши предположения об угрозах простыми словами. Вы защищаетесь от любопытного пользователя, запускающего клики, внешнего атакующего со скриптами или инсайдера с частичным доступом? Ответ меняет то, что считается «достаточно хорошо».

Наконец, определите критерии «пройдено» и «провалено», чтобы spot‑check завершился находками, а не ощущениями. Простые правила работают:

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

Если вы не можете описать, как выглядит провал, область всё ещё слишком размытa.

Подготовьте контекст для Claude Code

Проверка сработает только если модель смотрит в правильные места. Соберите небольшой набор кода и заметок, чтобы обзор выдал доказательства, а не догадки.

Начните с передачи критического для безопасности пути: точки входа запросов и кода, который решает, кто пользователь и что ему разрешено. Включите достаточный объём окружающего кода, чтобы показать, как данные текут.

Практичный пакет обычно включает:

• Входы аутентификации: парсинг сессии/JWT, настройки cookie, колбэки логина, middleware аутентификации
• Маршруты и обработчики: контроллеры, RPC‑методы, GraphQL‑резолверы, обработчики фоновых задач
• Слой данных: ORM‑запросы, хелперы для сырых SQL, строители запросов, миграции для чувствительных таблиц
• Правила доступа: проверки ролей, проверки владения, флаги функций, эндпоинты только для админов
• Валидация: валидаторы схем запросов, обработчики загрузок файлов, код десериализации

Добавьте пару строк с информацией об окружении, чтобы предположения были явными: сессии vs JWT, где живут токены (cookie или заголовок), поведение обратного прокси или API‑шлюза, очереди/cron‑воркеры и любые «только внутренние» эндпоинты.

Перед тем как искать баги, попросите инвентаризацию: точки входа, привилегированные эндпоинты и хранилища данных, с которыми работают. Это предотвращает пропуски поверхностей.

Также согласуйте формат вывода, который вынуждает давать конкретные находки. Простая таблица работает хорошо: Находка, Серьёзность, Затронутый эндпоинт/файл, Доказательства (точный фрагмент или диапазон строк), Сценарий эксплуатации, Предложение исправления.

Пошаговый рабочий процесс для 30–60‑минутного ревью

Разбейте по времени:

• 10 минут на ориентацию
• 15–30 минут на трассировку потоков
• 10 минут на отчёт

Цель — не идеальное покрытие. Это небольшой набор проверяемых находок.

Держите приложение открытым, пока читаете. Пройдитесь по UI и посмотрите, какие запросы отправляются. Заметки должны указывать на конкретные эндпоинты, параметры и источники данных.

Рабочий процесс, уместный в одной сессии:

1. Набросайте точки входа и границы доверия. Отметьте публичные маршруты, маршруты для авторизованных, админские маршруты, вебхуки, загрузки и колбэки третьих сторон. Пометьте, где данные пересекают границу от контролируемых пользователем до доверяемых сервером.
2. Для каждого важного эндпоинта запишите, что подтверждает личность и где это происходит. Если проверка в «middleware», подтвердите, что каждый маршрут действительно его использует.
3. То же для авторизации. Выберите одно рисковое действие (просмотр данных других пользователей, изменение ролей, экспорт, удаление) и проследите решение о праве до запроса к базе данных.
4. Проследите пользовательский ввод до сингков. Отследите один параметр от запроса до SQL/ORM‑запросов, рендеринга шаблонов, выполнения команд, URL‑запросов (SSRF), редиректов и файловых путей.
5. Сканируйте потоки секретов во время трассировки. Ищите токены в логах, клиентском коде, сообщениях об ошибках, дампах окружения и слабых схемах хранения.

Полезная привычка: для каждого «кажется в порядке» запишите, как бы вы это сломали. Если вы не можете описать способ взлома, вероятно, вы не проверили это достаточно тщательно.

Проверки аутентификации: докажите, кто пользователь

Аутентификация — момент, когда приложение решает: «этот запрос принадлежит этому человеку». Быстрая проверка не требует чтения каждой строки. Нужно найти место, где устанавливается личность, и проверить обходные пути и пути отказа.

Найдите границу доверия: где личность впервые создаётся или принимается? Это может быть cookie сессии, JWT Bearer токен, API‑ключ или mTLS на краю. Попросите Claude Code указать точный файл и функцию, которая превращает «аноним» в user id, и перечислить все другие пути, которые это же делают.

Проверки аутентификации, на которые стоит взглянуть:

• Назовите все входные точки аутентификации (веб‑логин, API‑токены, мобильная аутентификация, внутренняя сервис‑аутентификация) и убедитесь, что они сходятся к единой модели идентичности.
• Проверьте логин и сброс пароля на предмет ограничений по частоте, блокировок и возможности перечисления пользователей (различные сообщения об ошибке или время ответа для существующих и несуществующих аккаунтов).
• Проверьте сессии и cookie: HttpOnly, Secure, SameSite, срок жизни, ротация при входе и смене привилегий, инвалидирование при выходе (на стороне сервера, а не просто «удалить cookie»).
• Проверьте MFA и восстановление доступа так, чтобы путь восстановления не был слабее MFA (например, восстановление по email, которое обходится MFA).
• Проверьте логирование неудач аутентификации: полезно для эксплуатации, но не выводите детали, которые помогают атакующим (никаких подсказок «пользователь существует», никаких дампов токенов).

Практический пример: если письма для сброса пароля возвращают «аккаунт не найден», это быстрая проблема перечисления. Даже при нейтральном сообщении, различия по таймингу могут выдавать ту же информацию — проверьте время ответа.

Проверки авторизации: докажите, что пользователю разрешено

Авторизация — вопрос, который приносит наибольший вред при ошибках: «Разрешено ли этому пользователю выполнить это действие над этим ресурсом?» Быстрая проверка должна намеренно пытаться сломать это предположение.

Опишите роли и права простым человеческим языком. Держите это понятно:

• Владелец может приглашать участников
• Участник может редактировать свой профиль
• Саппорт может просматривать платёжные данные, но не менять тариф
• Админ может удалять проекты

Затем проверьте, что каждое чувствительное действие проверяет авторизацию на сервере, а не только в интерфейсе. Кнопки могут быть скрыты, маршруты — заблокированы в клиенте, но атакующий всё ещё может вызвать API напрямую.

Быстрый скан, который обычно находит реальные проблемы:

• Найдите эндпоинты/мутации, которые создают, удаляют, экспортируют, меняют роли или дают доступ к биллингу
• Для каждого найдите проверку прав на стороне сервера (не на фронте)
• Ищите ID, контролируемые пользователем (projectId, userId, orgId) и подтвердите проверки владения
• Убедитесь, что пути для админов «проваливаются закрыто», если роли нет
• Проверьте границы тенантов: orgId/accountId должны браться из контекста сессии, а не только из входного запроса

Классический запах IDOR прост: запрос вроде GET /projects/{id}, где {id} контролируется пользователем, и сервер загружает ресурс без проверки, что он принадлежит текущему пользователю или тенанту.

Промпт, который заставит дать реальный ответ:

«Для этого эндпоинта покажите точный код решения о доступе и перечислите конкретные условия, при которых пользователь из другого orgId сможет получить доступ. Если таких нет, объясните почему, с указанием файлов и функций.»

Валидация входных данных: блокируйте плохие данные как можно раньше

Большинство быстрых проблем веб‑приложений начинается с пропуска: приложение принимает входные данные, которых разработчик не ожидал. Рассматривайте «вход» как всё, чем может управлять пользователь или другая система, даже если это кажется безобидным.

Начните с перечисления входов для проверяемого эндпоинта:

• Значения в строке запроса и пути URL
• Поля тела запроса (включая вложенный JSON)
• Заголовки (авторизационные заголовки, Content‑Type, Forwarded IP)
• Cookies
• Загрузки файлов (имя, размер, тип, метаданные)

Валидация должна происходить как можно ближе к точке входа в приложение, а не глубоко в бизнес‑логике. Проверьте базовые вещи: тип (строка vs число), максимальная длина, обязательность и формат (email, UUID, дата).

Для известных значений, таких как роли, статусные поля или направления сортировки, предпочитайте allowlist. Это сложнее обойти, чем «блокировать несколько плохих значений».

Также проверьте обработку ошибок. Если приложение отклоняет вход, не возвращайте сырой ввод в ответе, логах или UI. Именно так мелкие баги в валидации превращаются в утечки данных или помощников для инъекций.

План «плохого ввода» для рискованных эндпоинтов (логин, поиск, загрузка, админ‑действия):

• Строки чрезмерной длины (10 000+ символов)
• Неподходящие типы (массив вместо строки)
• Неожиданные значения перечисления
• Спецсимволы, меняющие смысл
• Пустые значения для обязательных полей

Пример: параметр сортировки, принимающий любую строку, может превратиться в фрагмент SQL позже. Allowlist вроде "date" или "price" предотвращает такой класс ошибок заранее.

Частые поверхности для инъекций, которые стоит быстро просканировать

Большинство быстрых ревью находят проблемы в одних и тех же местах: где входные данные интерпретируются как код, запрос, путь или URL. Здесь вы ищете моменты «ввод пересекает границу доверия».

Прослеживайте данные от точек входа (query params, заголовки, cookie, загрузки, админ‑формы) до того места, где они используются.

Быстрые цели сканирования

Ищите эти паттерны и требуйте конкретного места вызова и примера полезной нагрузки для каждого:

• SQL‑инъекция: строки, собираемые вручную, динамический ORDER BY, и построители IN (...), которые склеивают пользовательские значения
• XSS: рендеринг HTML, шаблоны, превью Markdown, редакторы с богатым текстом, где предполагают «очистку позже»
• Command injection: вызовы оболочки вокруг обработки изображений, инструментов PDF, бэкапов или шагов convert, которые получают флаги от пользователя
• SSRF: фетч URL для вебхуков, предпросмотров ссылок, импортов по URL и внутренних чеков состояния, принимающих URL от пользователя
• Path traversal: эндпоинты скачивания файлов, распаковки zip и конвейеры загрузки, которые затем читают файлы по имени

Также следите за десериализацией и инъекциями шаблонов. Всё, что парсит пользовательский JSON, YAML или шаблонные строки, может скрывать риск, особенно если поддерживаются кастомные типы, выражения или серверный рендеринг.

Если функция принимает URL, имя файла или форматированный текст, предполагайте возможность злоупотребления, пока не докажете обратное кодовыми путями и тестами.

Обращение с секретами: найдите утечки и слабое хранение

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

Типичные места появления секретов:

• Переменные окружения и файлы конфигурации приложения
• Вывод CI и логи сборки (включая логи упавших деплоев)
• Клиентские бандлы и мобильные сборки (всё, что отправляется пользователям)
• Отладочные эндпоинты, страницы состояния и админ‑инструменты
• Страницы ошибок, трейсбеки и аналитические события

Потом требуйте конкретного ответа: если секрет раскрыт сегодня, что будет дальше? Хорошая система имеет путь ротации (выдача нового ключа), отзыва (деактивация старого) и быструю процедуру деплоя. Если ответ «мы поменяем позже», трактуйте это как находку.

Принцип наименьших привилегий — ещё одно быстрое улучшение. Инциденты усугубляются из‑за чрезмерных прав. Ищите пользователей БД, которые могут удалять таблицы, токены третьих сторон с управленческими правами или ключи, используемые в разных окружениях. Предпочитайте по одному ключу на сервис/окружение с минимальным набором прав.

Быстрые промпты для spot‑check, которые можно скопировать в Claude Code:

• «Поищи захардкоженные токены, пароли и приватные ключи. Назови точные пути файлов и паттерны строк, по которым ты искал.»
• «Найди код, который логирует заголовки запросов, cookie, переменные окружения или целые объекты ошибок. Покажи строки логов и какие чувствительные поля могут там оказаться.»
• «Проверь, могут ли секреты попасть в снимки, экспорты или артефакты сборки. Определи, что захватывается и где хранится.»

Наконец, подтвердите защитные меры: блокируйте секреты в системе контроля версий (pre‑commit/CI проверки) и убедитесь, что бэкапы или снимки не содержат открытых учётных данных. Если платформа поддерживает снимки и откаты, проверьте, что секреты внедряются во время выполнения, а не вшиваются в образ.

Промпты, которые заставят дать конкретные находки (шаблоны)

Незначительные промпты дают расплывчатые ответы. Заставьте модель взять на себя обязательство: точные места, трассировка, repro и что опровергло бы вывод.

Используйте по одному шаблону за раз, затем попросите переработать после того, как вы подтвердите или отклоните деталь.

• Доказательства на уровне файла: «Просканируй репозиторий на предмет auth, sessions, tokens и middleware. Назови точные файлы, функции и диапазоны строк. Процитируй релевантные фрагменты. Если не можешь указать код, скажи «доказательств не найдено».»
• Трассировка от входа до сингка: «Выбери один пользовательский ввод (заголовок, query, body, cookie). Покажи поток данных пошагово от точки входа до использования (SQL, HTML, shell, шаблон, редирект, файловый путь). Перечисли каждую функцию в цепочке.»
• Шаги воспроизведения: «Дай минимальные шаги воспроизведения с curl (метод, шаблон URL, заголовки, тело). Включи ожидаемый код статуса и пример ответа при успехе/неудаче. Укажи предположения (роли, состояние аутентификации).»
• Контроль ложных срабатываний: «Что опровергло бы эту находку? Перечисли 2–3 проверки: флаги конфигурации, порядок middleware, валидация allowlist, параметризованные запросы, экранирование фреймворком. Если что‑то из этого присутствует, объясни, как меняется риск.»
• Наименьшее безопасное исправление + тест: «Предложи наименьшее изменение, которое блокирует проблему, не ломая валидные кейсы. Затем опиши один тест (имя, цель, вводы, ожидаемый результат). Если есть компромиссы, опиши их.»

Если вывод всё ещё кажется расплывчатым, зафиксируйте его:

«Отвечай только: путь файла, имя функции, рискованная строка и одно предложение об эффекте.»

Реалистичный пример: как превратить догадку в подтверждённую проблему

Эндпоинты обновления профиля часто скрывают ошибки контроля доступа. Вот небольшой кейс, который можно пройти через чеклист.

Сценарий: API‑эндпоинт обновляет профиль пользователя:

PATCH /api/profile?accountId=123 с JSON вроде { "displayName": "Sam" }.

Вы просите Claude Code найти обработчик, проследить использование accountId и доказать, проверяет ли сервер владение.

Что часто всплывает:

• Аутентификация: запрос требует сессии или токена, поэтому кажется защищённым.
• Авторизация: обработчик доверяет accountId из строки запроса и обновляет этот аккаунт без проверки, что он совпадает с залогиненным пользователем.
• Валидация входа: displayName обрезается, но accountId не валидируется как целое число.
• Поверхность инъекции: SQL строится конкатенацией строк как "... WHERE account_id=" + accountId.

Хороший отчёт будет конкретным:

• Серьёзность: Высокая (IDOR + возможная SQL‑инъекция)
• Доказательства: запрос с валидной аутентификацией меняет другой аккаунт при изменении accountId; SQL формируется из ненадёжного ввода
• Исправление: игнорировать accountId от клиента, использовать id аутентифицированного пользователя на сервере; параметризовать запрос
• Тест: попытка обновить другой аккаунт => ожидать 403; отклонять нечисловой accountId

После патча быстро повторно проверьте:

• Повторите тот же запрос с другим accountId и подтвердите отказ.
• Убедитесь, что в логах видно, что сервер использует аутентифицированный id, а не параметр запроса.
• Подтвердите, что запрос использует плейсхолдеры/параметры, а не конкатенацию строк.
• Запустите негативный тест для неверного ввода (буквы, очень большое число).

Частые западни, из‑за которых spot‑checks пропускают реальные проблемы

Самый быстрый путь пропустить уязвимость — доверять тому, что кажется соблюдённым в UI. Скрытая или отключённая кнопка — не проверка прав. Если сервер всё равно принимает запрос, любой может повторить его с другим user ID, ролью или напрямую через API.

Ещё одна частая ошибка — расплывчатая постановка задачи. «Сделай ревью безопасности» обычно даёт общий отчёт. Spot‑check нуждается в жёсткой области (какие эндпоинты, какие роли, какие данные) и строгом формате вывода (имя файла, функция, рискованная строка, минимальный repro).

То же правило для ИИ‑вывода: не принимайте утверждения без указаний. Если находка не содержит конкретного места в коде и пошагового способа триггера, считайте её неподтверждённой.

Быстрые причины, по которым spot‑checks сбиваются с пути

Эти ловушки повторяются:

• Предположение «только для админа», потому что это админская страница, а не потому, что сервер это проверяет
• Запрос широкого результата вместо «покажи точный запрос, который обходит X»
• Принятие «возможной SQL‑инъекции» без указания места сборки запроса и пути ввода
• Пропуск неочевидных входных точек: вебхуки, планировщики, инструменты импорта и внутренние админ‑действия
• Патч симптомов (добавление фильтра или регекса) вместо устранения корня (отсутствия валидации или явной авторизации)

Если вы замечаете, что постоянно добавляете фильтры для новых краёв, остановитесь. Исправление обычно проще и раньше: валидируйте ввод на границе и сделайте проверки авторизации явными и централизованными, чтобы все пути их использовали.

Быстрые проверки перед релизом

Это не заменяет полный ревью, но ловит ошибки, которые проскакивают, когда все устали. Сосредоточьтесь на том, что можно быстро доказать: запрос, страницу или строку лога.

Пять быстрых spot‑checks, которые обычно окупаются:

• Аутентификационное трение: попробуйте 10 неудачных логинов подряд. Видны ли ограничения по частоте, блокировки или хотя бы замедление? Можно ли по сообщениям об ошибке или таймингу понять, существует ли email?
• Авторизация путём подстановки ID: возьмите реальный ресурс (заказ, счёт, профиль). Измените ID в URL, теле JSON или переменных GraphQL. Получаете ли вы чужие данные, хоть и «просто метаданные»?
• Ограждения ввода: для ключевых полей (email, имя, поиск, загрузка файла) попробуйте очень длинные строки, странный Unicode и неожиданные типы (число вместо строки). Накладываются ли ограничения длины и allowlist там, где это важно?
• Утечка секретов: поищите в недавних логах и клиентских бандлах токены, API‑ключи, JWT или заголовок «Authorization: Bearer». Проверьте страницы ошибок. «Это только в staging» часто становится «это попало в прод».
• Поверхности инъекций: ищите конкатенацию строк в SQL, фильтрах, рендеринге шаблонов, shell‑командах или URL‑редиректах. Если ввод попадает в одно из этих мест без жёсткой валидации, считайте риск активным, пока не покажете обратное.

Запишите топ‑3 исправления, которые вы можете выпустить на этой неделе, а не список желаний. Пример: (1) добавить rate limiting для логина и сброса пароля, (2) принудительно проверять владение на эндпоинте «get by id» на сервере, (3) ограничить длину ввода и отклонять неожиданные символы в поле поиска.

Следующие шаги: встроите этот чеклист в процесс сборки

Spot‑check даёт результат только если находки влияют на то, что вы выпускаете. Относитесь к этому чеклисту как к небольшому повторяемому шагу сборки, а не к одноразовой спасательной операции.

Преобразуйте каждую находку в задачу в бэклоге, понятную и с доказательствами:

• Исправление: что изменится в коде или конфиге
• Тест: как доказать, что проблема закрыта (один запрос, один юнит‑тест, один шаг QA)
• Владелец: один ответственный человек
• Целевая дата: следующий релиз или конкретный день
• Доказательства: файл/эндпоинт и точный запрос или полезная нагрузка, показавшие проблему

Выберите ритм, соответствующий риску и размеру команды. Для многих команд лучше — каждой релиз. Если релизы частые, делайте 30–60‑минутное ревью ежемесячно и короткую проверку перед релизом.

Упростите повторение, создав переиспользуемый пакет промптов и шаблон чеклиста. Держите промпты сфокусированными на конкретных результатах: покажи маршрут, проверку, падающий запрос и ожидаемое поведение. Храните пакет там, где команда уже работает, чтобы он не терялся.

Если вы строите приложения через чат, встраивайте чеклист в планирование. Добавляйте короткую заметку о «безопасных предположениях» для аутентификации/авторизации, вводов и секретов, а затем запускайте spot‑check сразу после первой рабочей версии.

Платформы вроде Koder.ai (koder.ai) хорошо вписываются в эту привычку, потому что позволяют быстро итератировать, сохраняя контрольные точки ревью. Использование снимков состояния и откатов вокруг рискованных изменений упрощает выпуск исправлений безопасности без остановки, если что‑то ломается.