Практические статьи об аудите 152-ФЗ и ручном ревью кода: что реально проверяется, где чаще всего ломается и как это исправить.
Года полтора назад мне достался магазин, который продавал БАДы и собирался перейти на маркировку «Честный знак». Задача звучала скучно: подключить проверку кодов при приёмке и сборке заказа. На деле там оказалась одна деталь, из-за которой я до сих пор привожу этот кейс как пример, когда архитектурное решение важнее самого кода.
Система падала примерно раз в шесть-восемь часов. Не полностью, но достаточно заметно: часть запросов начинала висеть, потом сервис переставал принимать новые соединения, потом его перезапускали, и всё повторялось заново. Классическая картина для продакшена, где что-то утекает, а никто пока не знает, что именно.
Если погуглить этот вопрос, выдача завалена сервисами, которые обещают проверить сайт за минуту и показать отчёт сразу после того, как вы оставите телефон. Звучит заманчиво, но стоит понимать, что именно вы получаете за эту минуту, прежде чем решать, этого достаточно или нет.
Поле для ввода промокода обычно последнее место, где кто-то ждёт уязвимость. Это не форма регистрации, не поле поиска, не комментарии, где все уже привыкли фильтровать ввод. Просто текстовое поле на странице корзины, куда вбивают буквы и цифры и жмут «Применить». Именно поэтому там и обнаружилась дыра, которую я нашёл на одном из e-commerce проектов, где отвечал за backend довольно долго.
Клиенты часто пишут мне с формулировкой в духе «нужен пентест нашего сайта», а когда начинаем обсуждать детали, выясняется, что на самом деле человеку нужен не пентест, а ручной аудит кода, или наоборот. Путаница понятная, обе услуги про безопасность и обе звучат как «проверьте, можно ли нас взломать». Разница в том, как именно проверяют и что в итоге находят.
Safekom я делал не для того, чтобы кого-то удивить, а чтобы иметь свою площадку, где можно спокойно проверять идеи по безопасности без риска сломать чужой продакшен. Это zero-knowledge менеджер паролей, то есть шифрование и расшифровка данных происходят только в браузере пользователя, а сервер хранит исключительно зашифрованный набор байт, который без ключа клиента бесполезен в принципе, даже для меня как владельца сервера.
LuchMarket я начинал без технического задания, без дедлайна и без клиента, который будет недоволен, если что-то пойдёт не так. Это одновременно и преимущество, и ловушка, потому что без внешнего давления очень легко бесконечно долго полировать то, что никто кроме тебя никогда не увидит.
Этот вопрос мне задают почти в каждом втором разговоре про поддержку, и ответ на него зависит не от размера сайта, как многие думают, а от того, насколько предсказуемо он живёт.
Моделирование угроз по методологии STRIDE часто объясняют через абстрактные диаграммы со стрелочками, и это создаёт у людей ощущение, что это какая-то академическая практика, далёкая от реальной разработки. На практике это просто список из шести конкретных вопросов к системе, и ответы на них иногда меняют архитектуру ещё до того, как написана первая строчка кода.
Многие владельцы сайтов уверены, что 152-ФЗ это баннер с кнопкой «Принять» в углу экрана. Поставил баннер, и закон соблюден. На практике проверка Роскомнадзора или суда начинается не с баннера, а с полного цикла обработки персональных данных: что вы собираете, где храните, кому передаете и на каком основании. Баннер при этом второстепенен, и часто он сам становится источником нарушения.
Автоматические сканеры стали стандартом: SAST в пайплайне, SCA для зависимостей, DAST по расписанию. Это правильная база, но у сканеров есть принципиальное ограничение: они ищут известные паттерны. Логическая ошибка в бизнес-логике, race condition в платежном сценарии, неочевидная цепочка от параметра в HTTP-заголовке до SQL-запроса — это то, что сканер пропускает, а человек находит.