Слабые пароли, секреты в коде, доступ к чужим заказам по номеру заявки — разбор частых ошибок безопасности небольших сайтов и что проверить в первую очередь, не дожидаясь утечки.
Небольшой сайт — не значит непривлекательная цель. У маленького интернет-магазина или сервиса заявок обычно нет отдела безопасности, зато есть базы клиентов, платежи и личные данные — то есть всё, ради чего вообще ищут уязвимости. Ниже — частые технические промахи, из-за которых чужие данные становятся доступны посторонним, и что стоит проверить в первую очередь. Особенно актуально, если сайт делали быстро, в том числе с помощью ИИ-инструментов, без отдельного этапа проверки безопасности.
Форма входа без ограничения числа попыток позволяет перебирать пароли автоматически, пока один не подойдёт. Базовая защита — лимит попыток и, где возможно, двухфакторная авторизация. Отдельная частая ошибка — использовать один и тот же пароль от админ-панели сайта, который уже «засветился» в утечке с другого, менее защищённого сервиса: базы скомпрометированных паролей утекают регулярно, и автоматический перебор по ним — стандартный первый шаг атаки.
Пароль от базы данных, ключи внешних API, токены ботов — если это прописано прямо в коде сайта (а не в переменных окружения, недоступных снаружи), любой, кто получит доступ к репозиторию или файлам сайта, получает и это. Особенно рискованно — публичные репозитории или код, отправленный кому-то «на проверку» без предварительной чистки секретов.
Кажется очевидным, но регулярно встречается: раздел администратора доступен по прямой ссылке без проверки авторизации — достаточно узнать или угадать адрес. Каждая admin-функция должна проверять не только «залогинен ли пользователь», но и «есть ли у него право это делать».
Если номер заказа, заявки или личного кабинета — это просто последовательное число, и система не проверяет, что запрашивающий имеет право видеть именно этот номер, достаточно поменять цифру в адресе, чтобы увидеть чужой заказ. Это одна из самых частых и самых недооценённых уязвимостей у молодых сайтов — сервер обязан на каждый запрос отдельно проверять принадлежность данных, а не полагаться на то, что номер «случайно узнать сложно».
Если форма или API принимает от пользователя весь объект целиком и сохраняет его как есть, пользователь может прислать не только ожидаемые поля (имя, телефон), но и служебные — например, свою роль или статус оплаты — и сервер молча их примет. Правильный подход — явно перечислять, какие именно поля можно менять через конкретную форму, и игнорировать всё остальное, что бы ни пришло в запросе.
Уведомление об оплате от платёжной системы должно быть подписано, и сайт обязан эту подпись проверять — иначе запрос «оплата прошла» можно отправить самому, напрямую, без реальной оплаты. Проверка факта поступления денег должна идти через API платёжной системы, а не через доверие к входящему уведомлению.
Пароли, токены и прочие чувствительные данные не должны попадать в текстовые логи в открытом виде — если лог утечёт (а логи часто хранятся менее защищённо, чем основная база), утечёт и всё, что в них записано. Отдельная точка риска — сторонние библиотеки и куски кода из чужих репозиториев, подключённые без проверки: код с нужной функциональностью может содержать и то, что туда не заказывали.
Если несколько одинаковых запросов (например, на списание баланса или активацию промокода) могут прийти одновременно, а сервер не предусматривает такую ситуацию, один и тот же промокод или бонус можно применить не один раз, а несколько — просто отправив запросы параллельно.
Ни один из этих пунктов не требует отдельного бюджета на аудит безопасности — это вопрос того, что именно проверяется на этапе разработки сайта и автоматизации на нём. Дешевле проверить это один раз при запуске, чем разбираться с утечкой данных клиентов постфактум.
Да — эти ошибки встречаются и в заказных проектах, особенно если задача была «сделать быстро». Стоит явно спросить у подрядчика про лимит попыток входа, проверку прав доступа к чужим данным по номеру и хранение секретов вне кода.
С самого простого технически и самого частого на практике: попробовать открыть чужой заказ или заявку, поменяв номер в адресной строке, и проверить, требует ли админ-панель авторизации по прямой ссылке.
Кроме технического устранения причины, по 152-ФЗ есть обязанность уведомить Роскомнадзор в течение 24 часов с момента обнаружения инцидента и предоставить результаты расследования в течение 72 часов — это уже не техническая, а юридическая часть реагирования.
Напишите пару строк о вашем бизнесе — отвечу в течение дня и назову точную цену.
Написать в Telegram