2026 год, роботы доставщики на улицах крупных городов, автоматические сканеры уязвимостей для QA, фреймворки разработки , которые позволяют написать код как для сайта по продаже авторских батонов и выпечки , так и портал для крупного медицинского бизнеса - все это в наличии и не вызывает удивления. Казалось бы чем нам как разработчикам или QA будет полезен пресловутый DevTools и вкладка Source...

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

Вспомним как анализировать Source

Идем по классической дорожке, на примере Яндекса (цели найти реальную уязвимость на Яндексе нет, но как пример алгоритма работы самое то) :

1. Открываем DevTools;

2. Переходим в вкладку Source;

3. Изучаем структуру файлов, если видим файл с именем API,Helper, Debug || Test уделяем им пристальное внимание. Пример под катом;

   Скрытый текст

   

4. Заходим в файл пробегаемся глазами, а затем поиском по коду ищем ключевые слова api, debug,secret || token и т.д. Пример под катом.

Скрытый текст

Раскрываем тему находок

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

• Служебные API без защиты

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

• Секреты

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

  Скрытый текст

  • accessKeyId / secretAccessKey — к AWS/Azure

  • api_key / API_SECRET — к платежкам, почтовым серверам

  • JWT_SECRET — подпись токенов

  • Токены Slack/TG/GitHub — к репозитолриям

  • admin:password — прямо в JS-комментарии

  Думаю тут опасность очевидна, от получения доступа к репозиторию до угона админки, если креды от нее были найдены в уязвимости. На практике чаще всего я встречал креды и токены от протухших/дезактивированных учеток, но пару раз довелось увидеть данные от админских учеток. Бороться с этим пожалуй можно только "вычитыванием" кода и настоятельным просьбам к коллегам из разработки удалять, а не коммитить.

  

Немного цифр от наших азиатских друзей и западных визави

В отчете, опубликованном в феврале 2026 года компанией Intruder, занимающейся кибербезопасностью и проведшей углубленное сканирование 5 миллионов приложений по всему миру, было выявлено более 42 000 конфиденциальных сообщений (секретов), обнаруженных в открытом виде в файлах JavaScript.
Источник - статья на портале https://m.ithome.com

Ряд исследований проведенных зарубежными командами показал - что 84% современных приложений «светят» через фронтенд от 3 до 5 недокументированных API-эндпоинтов. А ручной анализ кода позволяет найти на 156% больше таких путей, чем автоматические инструменты.
Источник - информация с портала https://www.linkedin.com (не доступен с IP адреса из РФ)

PS, рецепт для здоровья и пара слов на дорожку:)

Проблему обсудили, статистику посмотрели, но как лечить ?
Все очень просто , нет ничего лучше чем банальное код ревью и финальный чекап - проверка содержимого вкладки Source после деплоя глазами. Метод прост, эффективен и не требует тысячи п*п* часов в тайм трекере, главное выработать привычку!

P.S.S Перед тем как написать в обсуждении, что мы в команде за 10 лет ни разу ничего оставили на виду в коде Клиентской части (с), стоит помнить про парадокс выжившего *-*