Как уязвимости попадают в код и как их не допустить

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

Откуда берутся уязвимости

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

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

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

Копипаст без понимания. Берут кусок кода со Stack Overflow, не разобравшись, что он делает и безопасен ли.

Самые частые уязвимости

Инъекции. Когда пользовательский ввод попадает напрямую в запрос к базе или в команду. Классика — SQL-инъекция: через форму крадут или удаляют данные.

XSS (межсайтовый скриптинг). Вредоносный скрипт внедряется через ввод и выполняется у других пользователей — крадёт сессии, данные.

Небезопасная аутентификация. Слабые пароли, токены без срока годности, отсутствие защиты от перебора.

Открытые данные. API, которые отдают больше, чем нужно. Логи с паролями. Конфиги в публичном доступе.

Неправильные права доступа. Пользователь может получить доступ к чужим данным, просто поменяв номер в адресе.

Как не допустить — на этапе разработки

Проверять и фильтровать любой ввод. Всё, что приходит от пользователя — потенциально опасно, пока не доказано обратное.

Использовать проверенные подходы. Параметризованные запросы к базе (защита от инъекций), экранирование вывода (защита от XSS) — это стандарт, не изобретайте велосипед.

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

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

Code review. Второй человек смотрит код — half ошибок ловится на этом этапе.

Не хранить секреты в коде. Пароли, ключи, токены — в защищённых хранилищах, не в репозитории.

Почему это важно для заказчика

Когда вы заказываете разработку, безопасность кода — это не опция, а часть качества. Дешёвый код, написанный наспех, может обойтись дорого при утечке. Спрашивайте разработчика, как он защищает ввод, обновляет ли зависимости, делает ли review. Хороший подрядчик заложит безопасность с самого начала, а не будет латать дыры после взлома.

Уязвимости — это технический долг, который рано или поздно предъявляют к оплате. Профилактика на этапе разработки в разы дешевле, чем устранение последствий. Безопасный код стоит чуть дороже, но это страховка от куда больших потерь.