Забытый, но небесполезный: багхантинг во вкладке Source. Актуалочка для 2026 года

Значимый прорыв формирует отрасль ИИ: AntonCinet 28 минут назад Забытый, но небесполезный: багхантинг во вкладке Source. Актуалочка для 2026 года Простой 3 мин 290 Google Chrome JavaScript * Мнение 2026 год, роботы доставщики на улицах крупных городов, автоматические сканеры уязвимостей для QA, фреймворки разработки , которые позволяют написать код как для сайта по продаже авторских батонов и выпечки , так и портал для крупного медицинского бизнеса - все это в наличии и не вызывает удивления. Казалось бы чем нам как разработчикам или QA будет полезен пресловутый DevTools и вкладка Source...

Но в этом и заключается парадокс, вкладка Source остается актуальной даже в наш просвещённый век, ведь при грамотном поиске и толики удачи, в ней можно найти как медь в виде служебных ручек, так и золото в виде секретов. Вспомним как анализировать SourceИдем по классической дорожке, на примере Яндекса (цели найти реальную уязвимость на Яндексе нет, но как пример алгоритма работы самое то) : Открываем DevTools; Переходим в вкладку Source;Изучаем структуру файлов, если видим файл с именем API,Helper, Debug Test уделяем им пристальное внимание. Пример под катом;Скрытый текстЗаходим в файл пробегаемся глазами, а затем поиском по коду ищем ключевые слова api, debug,secret token и т.

Технические детали

Скрытый текстРаскрываем тему находокПо своему личному опыту найти в коде доступном Клиенту, можно все что угодно, начиная от дыр в логике, так и заканчивая служебными ручками, которые может использовать как угодно любой нашедший. Однако чаще всего я встречал два типа уязвимости - служебные API без защиты и секреты. Я думаю, что опасность первых как и вторых не стоит описывать как роман в двух частях, поэтому остановлюсь на описании риска тезисно и по возможности проиллюстрирую примерами из практики.

Служебные API без защиты Степень риска, от средней до критической. Как появляется проблема? Обычно довольно банально, разработчик оставляет debug ручки в коде, который доступен на клиентской части.

Сама по себе проблема может быть не критичной, если ручку нельзя использовать без токена или другого ключа, но очень часто подобные ручки может использовать любой нашедший, так как они не защищены. За несколько лет работы удалось увидеть проявление этой уязвимости как в безобидном виде - ручка которая позволяла присвоить статус "увжаемый" форумчанин на одной из тематических борд, так и в критическом виде, когда ручка позволяла управлять количеством товара доступного к покупке у продавцов на портале крафтовых изделий. Рекомендацию, которую я выработал для себя это защищать ТУЗом любые ручки, даже те , что мы используем для дебага и тестирования, ну и конечно проверять глазами то , что видно на Клиенте через DevTools.

СекретыСтепень риска, от минимальной до критической. Как появляется проблема? Типичный кейс это креды, токены или иные секреты , которые были использованы на этапе разработки и отладки разработчиками.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.