Берегите очко смолоду
Часть 9, финал — про то, что иногда лучший фикс — это удаление, и как вообще жить с теми, кто приходит с находками.

Что это значит для нормального проекта#

Безопасность не обязана превращаться в бесконечный список запретов. Часто лучший ход — убрать лишнюю поверхность: закрыть ненужную админку, выключить старый endpoint, удалить роль, которой никто не пользуется, забрать публичный доступ у служебной панели.

Чем меньше у сервиса ненужных дверей, тем проще его поддерживать. Это снижает риск для разработчиков и одновременно делает продукт понятнее для владельца.

Что это значит для нормального проекта#

Безопасность не обязана превращаться в бесконечный список запретов. Часто лучший ход — убрать лишнюю поверхность: закрыть ненужную админку, выключить старый endpoint, удалить роль, которой никто не пользуется, забрать публичный доступ у служебной панели.

Чем меньше у сервиса ненужных дверей, тем проще его поддерживать. Это снижает риск для разработчиков и одновременно делает продукт понятнее для владельца.

На одном из проектов мне всё-таки сломали базу. Не «нашли потенциальную дырку» — реально зашли. И первое, что хочется сделать в такой момент, — латать: закрыть конкретную щель, сменить пароль, накатить заплатку и выдохнуть.

Я сделал иначе. Сел и посмотрел на проект целиком: зачем здесь вообще отдельная админка, зачем бэкенд, зачем база, которая круглые сутки висит в сети и ждёт, пока её опять поковыряют. Оказалось — почти незачем. Контент менялся редко, логики было немного.

И вместо заплатки я снёс. Отдельную админку, бэкенд, саму БД. Проект переехал на статику с файловой CMS: контент стал обычными файлами в git, без базы и без публичной панели, которая 24/7 торчит наружу. Это был большой коммит «на удаление» — сотни файлов, десятки тысяч удалённых строк. Один из самых приятных коммитов в моей жизни, если честно.

Мысль за этим простая. Самый защищённый компонент — тот, которого нет. У несуществующей базы нельзя угнать дамп. У несуществующей админки нельзя подобрать пароль. Иногда правильный «фикс» — это не патч, а удаление.

YAGNI как модель безопасности#

Обычно YAGNI — «you aren't gonna need it» — подают как совет про чистоту кода: не пиши лишнего, не закладывайся на будущее, которое не наступит. Но у него есть второе дно, чисто про безопасность.

Каждый сервис, который вы подняли «на всякий случай», — это ещё одна постоянно открытая дверь. Лишняя база, лишний API, забытый staging, админка «чтобы удобнее было править» — всё это не просто код, это поверхность, которую кто-то будет щупать, пока вы спите. Чем меньше дверей, тем меньше можно открыть.

А «да кому я нужен» — это не модель угроз. Это анестезия. Боты не выбирают вас по значимости, они идут по спискам адресов. Меньше открытых дверей — меньше того, что найдут по списку.

Как работать с теми, кто приходит с находками#

За время этой истории ко мне приходили очень разные люди, и их стоит научиться различать спокойно, без паники.

Есть добросовестные багхантеры. Человек нашёл проблему, описал шаги, прислал отчёт, иногда подсказал, как чинить. Это нормально и полезно. Таким людям надо говорить спасибо — они делают вашу работу бесплатно и по-человечески.

А есть вымогатели. Приходит письмо, плотно набитое страшными словами: IDOR, мисконфиг, «у меня netcat и hap, я внутри», «полный доступ». Иногда за этим стоит реальная мелочь, иногда — вообще ничего, просто лексикон, рассчитанный на испуг. Бывает и хуже: платишь человеку серьёзные деньги за «помощь» или «молчание», а получаешь кидок и новое требование заплатить ещё.

Отсюда несколько уроков, которые дались мне дорого.

Страшное письмо — это не модель угроз. Набор баззвордов не равен взлому. Реагировать надо из понимания своей системы, а не из словаря того, кто вам пишет: открываете архитектуру, смотрите, возможно ли описанное у вас в принципе, и только потом делаете выводы.

Не платите за «доказательства» без чёткого скоупа и договора. «Дай денег, и я покажу» — это не аудит, это рычаг. Нормальная работа начинается с понятных рамок: что смотрим, что считается находкой, что за это будет.

И паника лечит не тот слой. Первое движение «сейчас сменю пароль» успокаивает нервы, но часто не закрывает реальную дыру, если проблема была в логике доступа, а не в украденном пароле.

Здоровый процесс вместо дёрганья#

Чтобы не жить от письма к письму, помогает скучный повторяемый цикл: audit → plan → fix → recheck. Сначала смотрим, что есть. Потом решаем, что и в каком порядке чиним. Потом чиним. Потом перепроверяем, что починили именно это и не сломали соседнее.

Отдельная важная часть — ловля ложных срабатываний. Изрядная доля «находок», что из автоматических сканеров, что из писем, оказывается не уязвимостями. Гнать фиксы ради галочки в таком же красном отчёте — это тоже вред: вы тратите силы и риск-бюджет не туда. Иногда правильный ответ — «это не баг, и вот почему».

И принятые риски стоит документировать. Прямо честно записать, например в README: вот это мы сознательно оставили так, по такой причине, это осознанное решение, а не недосмотр. Это спасает будущего вас от паники по поводу того, что вы сами когда-то решили.

Что из всего этого осталось#

Если вытряхнуть всю серию в несколько живых мыслей, а не в оглавление, получится примерно так.

Не верьте вводу — ни телу запроса, ни заголовку, ни вебхуку «от провайдера»; всё, что пришло снаружи, проверяйте у первоисточника. Падайте закрыто — пустой конфиг и непонятная ситуация должны означать «нельзя», а не «можно». Минимизируйте поверхность — каждый сервис, которого нет, не взломают. Берегите секреты — они утекают не там, где вы их прячете, а во фронтенде, в слоях образа и в общих ключах. И помните, что деньги — это про идемпотентность и подлинность, а не про красоту.

Ничего из этого не про паранойю и не про дорогие аудиты. Это несколько привычек, которые дешевле выработать заранее, чем оплачивать письмо со страшными словами потом.

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

Готовы к честному аудиту безопасности без паники и продажи страха? Напишите в Telegram или на почту — проведём спокойный разбор вашего проекта и составим план реальных улучшений.