Безопасность веб-приложения глазами заказчика: 15 вопросов к подрядчику до запуска

Короткий ответ: абсолютно защищённых веб-приложений не бывает, но большинство типовых проблем закрывается простыми мерами, о которых заказчик может спросить сам — без технического образования. Это хеширование паролей и лимиты на вход, проверка прав на сервере, HTTPS везде, резервные копии с проверкой восстановления, журнал действий, обновления библиотек и порядок с доступами подрядчика. Ниже — что спросить и какие ответы должны насторожить, а в конце сводная таблица из 15 вопросов.

Статья про то, как заложить безопасность в новый кабинет или сервис до запуска. Способы входа по телефону и их стоимость мы разбирали отдельно — в статье о входе по SMS или звонку, а ограничения на вход через иностранные сервисы — в материале о 199-ФЗ.

Почему безопасность — вопрос заказчика?

Потому что последствия ложатся на владельца сервиса: штрафы по 152-ФЗ, потерянные клиенты, простой бизнеса. Подрядчик пишет код, но решения о бюджете, сроках и о том, что отложить «на потом», принимает заказчик. Если безопасности нет в ТЗ, её чаще всего и нет в продукте.

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

Хорошая новость: чтобы задать правильные вопросы, не нужно разбираться в коде. Нужно понимать, что именно защищается — учётные записи, данные, деньги и доступность сервиса, — и требовать конкретных ответов вместо «у нас всё безопасно».

Вход и пароли: что спросить?

Спросите три вещи: как хранятся пароли, что происходит при подборе и есть ли второй фактор у администраторов. Правильные ответы: пароли хранятся только в виде хеша медленным алгоритмом, попытки входа ограничены, у ролей с широкими правами — дополнительный код.

• Хеш, а не шифрование. Пароль в базе не должен быть восстановим даже разработчиком. Если подрядчик говорит «пароли зашифрованы», уточните: зашифрованное можно расшифровать, а хеш — нет. Если сервис умеет «прислать ваш старый пароль на почту» — это плохой знак.
• Защита от перебора. После нескольких неудачных попыток вход замедляется или требует капчу, а на почту или в мессенджер владельцу аккаунта уходит уведомление. Это же касается формы восстановления пароля и отправки кодов: без лимитов их используют для рассылки SMS за ваш счёт.
• Сессии. Выход на одном устройстве, срок жизни сессии, возможность «выйти со всех устройств» после смены пароля. Особенно важно для кабинетов, куда заходят с общих компьютеров.
• Второй фактор для администраторов. Учётная запись, которая видит всех клиентов, — главная цель атаки. Для неё одноразовый код в приложении-аутентификаторе — разумный минимум.

Права доступа и роли: кто что видит?

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

Этот класс ошибок стоит на первом месте в списке OWASP Top 10 — открытого рейтинга самых распространённых уязвимостей веб-приложений. Поэтому на брифе стоит составить матрицу ролей: кто создаёт, читает, правит и удаляет каждую сущность — заявку, документ, счёт, пользователя.

• Клиент видит только свои записи, менеджер — записи своих клиентов, руководитель — всё, но без права удалять журнал.
• Выгрузка в Excel — отдельное право. Сотрудник, который может выгрузить всю базу одной кнопкой, — риск сам по себе.
• Принцип минимальных прав: новая роль по умолчанию не видит ничего, доступ выдаётся явно.
• Попросите показать на приёмке: зайти под клиентом и попробовать открыть чужую запись по прямой ссылке. Это проверка на пять минут.

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

Данные и резервные копии: что будет, если сервер умрёт?

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

• Частота. Для большинства кабинетов достаточно ежедневной копии базы; для сервисов с платежами и активной работой — чаще. Вопрос к себе: сколько часов работы вы готовы потерять.
• Место. Другой сервер или другое хранилище, желательно в другом дата-центре. Для персональных данных — тоже в России.
• Глубина. Несколько последних копий, а не одна перезаписываемая. Если ошибку заметили через неделю, вчерашняя копия уже содержит испорченные данные.
• Проверка. Раз в квартал восстановить копию на тестовый сервер и замерить время. Это и есть реальный срок вашего простоя при аварии.
• Шифрование трафика. HTTPS для всего: сайта, API, админки. Бесплатные сертификаты выпускаются и продлеваются автоматически, так что причин работать по HTTP нет.

Отдельно — секреты: пароли к базе, ключи платёжного сервиса, токены интеграций. Им не место в коде и в репозитории. Если ключ хоть раз попал в историю Git, его нужно перевыпустить, а не просто удалить из файла.

Журналы и мониторинг: как узнать об атаке?

Без журнала вы не узнаете, что произошло, а без мониторинга — что вообще что-то произошло. Минимум: журнал действий пользователей в самом приложении и алерты о падении сервиса и всплесках ошибок, которые получает конкретный человек, а не общий ящик.

В журнал действий стоит писать входы и неудачные попытки, смену ролей и паролей, выгрузки, удаления и изменения платёжных реквизитов — с датой, пользователем и IP-адресом. Такой журнал нужен не только против взлома: он отвечает на вопрос «кто удалил договор» в обычной рабочей ситуации.

Мониторинг на старте простой: проверка доступности раз в минуту, оповещение в Telegram при падении, отчёт об ошибках сервера. Если журнал и алерты никто не читает, их как будто нет — договоритесь, кто реагирует и в какое время. Для персональных данных это не формальность: по ч. 3.1 ст. 21 152-ФЗ оператор обязан сообщить в Роскомнадзор о неправомерной или случайной передаче (предоставлении, распространении, доступе) персональных данных в течение 24 часов с момента выявления инцидента, а о результатах внутреннего расследования — в течение 72 часов. Без журнала расследовать нечего.

Обновления и доступы подрядчика: что будет после запуска?

Код приложения состоит в основном из чужих библиотек, и в них регулярно находят уязвимости. Спросите, как подрядчик узнаёт о них и кто обновляет зависимости после запуска. Второй вопрос — доступы: сервер, домен, база и репозиторий должны быть оформлены на вас.

• Проверка зависимостей. Менеджеры пакетов умеют автоматически сверять библиотеки с базами известных уязвимостей. Хороший ответ — «проверка встроена в сборку, критичные обновления ставим в течение нескольких дней».
• Кто обновляет после гарантии. Обновления — работа, которая не заканчивается. Если сопровождения нет, кто-то в вашей компании должен хотя бы раз в месяц ставить обновления сервера.
• Аккаунты на вас. Подрядчик работает по выданным ему доступам, а не владеет вашим доменом. Подробно о проверке подрядчика до оплаты — в статье как проверить студию разработки.
• После окончания работ. Смените пароли, отзовите ключи SSH и токены подрядчика, если сопровождение не продолжается.

Как это устроено у нас. По тарифу «Веб-приложение / SaaS» — от 160 000 ₽, от 10 дней — вы получаете исходный код в вашем Git-репозитории и доступы к серверу, базе данных, домену и платёжному кабинету. В договоре есть раздел о конфиденциальности: стороны не разглашают коммерческие данные, доступы и персональные данные в течение срока договора и трёх лет после. После запуска — 14 дней бесплатной поддержки и гарантия 30 календарных дней с даты акта; обновления и мониторинг дальше — в поддержке от 7 900 ₽ в месяц, состав абонентки считаем после брифа.

Персональные данные: что требует закон?

Если в приложении есть имена, телефоны или почта клиентов, вы — оператор персональных данных, и защита — обязанность по закону. Статья 19 152-ФЗ перечисляет меры: от определения угроз до учёта доступа и контроля защищённости.

Среди мер ч. 2 ст. 19 — определение угроз, правила доступа и регистрация действий с данными, обнаружение несанкционированного доступа и реагирование на него, восстановление данных после атаки, оценка эффективности мер до ввода системы в эксплуатацию. Почти каждая из них — это пункт технического задания: роли, журнал, мониторинг, резервные копии. Конкретные уровни защищённости и требования к ним устанавливает Правительство, а состав мер для каждого уровня — ФСТЭК и ФСБ.

Ответственность ощутимая. По ст. 13.11 КоАП (текст на октябрь 2026 года) за несообщение в Роскомнадзор об утечке юрлицу грозит 1–3 млн ₽ (ч. 11), за утечку данных от 1 тыс. до 10 тыс. человек — 3–5 млн ₽ (ч. 12), а при повторной утечке — оборотный штраф от 1 до 3 % выручки (ч. 15). Требования к хранению данных в России, уведомлению и согласию разобраны в статье где хранить данные сайта по 152-ФЗ.

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

Проект	Что защищаем в первую очередь	Обязательный минимум	Что можно отложить
Внутренний сервис на 5–20 сотрудников	Учётные записи и рабочие данные компании	HTTPS, хеширование паролей, роли, ежедневные копии базы, отключение уволенных	Внешний пентест, отдельная система мониторинга событий
Личный кабинет клиентов с заявками и документами	Персональные данные и чужие документы	Всё из строки выше плюс проверка прав на сервере для каждого запроса, лимиты на вход, журнал действий, согласие и политика по 152-ФЗ	Сертифицированные средства защиты — решение принимается после оценки с юристом
Сервис с оплатой, тысячами пользователей и API для партнёров	Деньги, платёжные статусы, ключи интеграций	Всё из строк выше плюс второй фактор для администраторов, ротация ключей, алерты на аномалии, копии в другом дата-центре	Почти ничего: внешнюю проверку стоит планировать до публичного запуска

Когда нужна внешняя проверка на уязвимости?

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

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

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

15 вопросов к подрядчику: сводная таблица

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

Если на несколько вопросов подряд звучит «не переживайте, всё безопасно», просите показать: журнал, настройку копий, тест прав. Показать можно за полчаса на демонстрации.

№	Вопрос	Хороший ответ	Тревожный ответ
1	Как хранятся пароли пользователей?	Только в виде хеша медленным алгоритмом, вроде bcrypt или Argon2	«Зашифрованы» или «в базе, но она закрыта»
2	Что будет при подборе пароля?	Лимит попыток, задержка или капча, уведомление владельцу	«Пароли сложные, подобрать нельзя»
3	Есть ли второй фактор для администраторов?	Да, хотя бы для ролей с доступом ко всем данным	«Администратор у вас один, не нужно»
4	Где проверяются права доступа?	На сервере, при каждом запросе к данным	«Кнопки скрыты в интерфейсе»
5	Можно ли получить чужую запись, поменяв номер в адресе?	Нет, это проверяется тестом на каждую роль	Пауза и «надо посмотреть»
6	Весь ли трафик идёт по HTTPS?	Да, включая API и админку, с автоматическим продлением сертификата	«Сертификат есть на главной»
7	Как часто делаются резервные копии и где лежат?	По расписанию, вне основного сервера, с проверкой восстановления	«Хостинг что-то делает»
8	Когда последний раз копию восстанавливали?	Называют дату и сколько заняло	«Пока не было нужды»
9	Что пишется в журнал действий?	Входы, смена прав, выгрузки, удаления — с датой и пользователем	«Логи сервера есть»
10	Кто узнает, если сервис упадёт или начнётся атака?	Конкретный человек получает алерт	«Клиенты напишут»
11	Как обновляются библиотеки?	Есть автоматическая проверка известных уязвимостей и план обновлений	«Работает — не трогаем»
12	Где хранятся пароли к базе и ключи API?	В переменных окружения или хранилище секретов, не в репозитории	Молчание или «в конфиге»
13	На кого оформлены сервер, домен и репозиторий?	На заказчика, подрядчик работает по выданным доступам	«На нас, так удобнее»
14	Где физически стоит база с данными клиентов?	Называют дата-центр в России	«В облаке»
15	Что вы сделаете после окончания работ с доступами?	Передадим, вы смените пароли, наши ключи удалим	Вопрос застаёт врасплох

Какие ошибки заказчики делают чаще всего?

Главная ошибка — откладывать безопасность до «после запуска»: роли и хранение данных дорого переделывать в работающем продукте. Остальные типичны и легко исправляются, если знать о них заранее.

• Один общий логин администратора на всех сотрудников — потом невозможно понять, кто что сделал.
• Пароли от сервера и базы в общем чате или таблице.
• Тестовый стенд с копией реальной базы клиентов в открытом доступе.
• Резервные копии на том же сервере, что и сайт.
• Домен и хостинг оформлены на сотрудника или подрядчика.
• Сбор лишних данных «на всякий случай»: то, чего нет в базе, утечь не может.

Когда всё это избыточно. Если у вас статичный лендинг без кабинета и форм, большая часть списка не нужна — хватит HTTPS, обновлений и копии. Не нужен и пентест прототипа, который видят пять человек из команды: тратить бюджет на проверку стоит, когда в системе появились реальные данные и пользователи.

Короткие ответы на частые вопросы

Можно ли сделать веб-приложение, которое невозможно взломать?

Нет, такого обещания честно дать нельзя. Реальная цель — закрыть типовые уязвимости, ограничить ущерб от взлома ролями и разделением доступов и уметь быстро восстановиться из резервной копии.

Кто отвечает за утечку данных: заказчик или разработчик?

Перед законом и Роскомнадзором отвечает оператор персональных данных — обычно компания-владелец сервиса. Отношения с подрядчиком регулирует договор: у нас, например, есть раздел о конфиденциальности, включая доступы и персональные данные.

Нужен ли пентест небольшому личному кабинету?

Чаще всего на старте — нет: достаточно базовых мер и проверки прав по чек-листу. Внешнюю проверку стоит заказать, когда в сервисе деньги, тысячи пользователей, чувствительные данные или этого требует крупный клиент.

Сколько стоит защита в веб-приложении на заказ?

Базовые меры — вход, восстановление пароля, роли, HTTPS — входят в тариф «Веб-приложение / SaaS» от 160 000 ₽. Внешний аудит безопасности сторонней компании в эту цену не входит и оплачивается отдельно.

Что делать после того, как подрядчик закончил работу?

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

Услуги и кейсы по теме: веб-приложения и SaaS · поддержка сайта от 7 900 ₽/мес · цены и сроки