Простой

3 мин

0

Вспомним как анализировать 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, рецепт для здоровья и пара слов на дорожку:)