Как использовать Chrome DevTools для выявления утечек данных на сайтах

Представьте: вы разрабатываете или администрируете сайт, и нужно проверить, не отправляет ли он куда-то лишнее. Телефон пользователя, токен сессии, содержимое формы — всё это может утекать на сторонние серверы без вашего ведома. Причём не обязательно из-за злого умысла. Чаще всего виноваты кривая интеграция аналитики, забытый скрипт или неправильно настроенный прокси.

Chrome DevTools — это не только про отладку CSS. Его инструменты позволяют увидеть каждый запрос, который делает страница, и понять, куда и что именно отправляется. Разберёмся, как это искать на практике.

Начнём с панели Network

Откройте DevTools (F12 или Ctrl+Shift+I), перейдите на вкладку Network, поставьте фильтр All и обновите страницу. Теперь вы видите каждый запрос: картинки, шрифты, скрипты, API-вызовы, веб-сокеты.

Сразу включите полезные опции:

• Preserve log — сохраняет лог запросов при переходе между страницами. Без этого при навигации всё обнулится и вы потеряете цепочку вызовов.
• Disable cache — отключает кэш, чтобы запросы шли каждый заново, а не из кэша браузера.
• Hide data URLs — скрывает встроенные в страницу картинки и прочий мусор, чтобы глаза не разбегались.

Теперь смотрите на колонку Initiator. Она показывает, какой скрипт инициировал запрос. Если вы видите, что картинка запрашивается из скрипта аналитики — это повод присмотреться.

Фильтруем по типу запросов

Клик по иконке фильтра вверху панели Network — и вы можете оставить только нужные типы запросов. Для поиска утечек данных нас интересуют:

• Fetch/XHR — все API-запросы и AJAX-вызовы. Именно здесь чаще всего уходят данные форм, токены, персональная информация.
• WS — веб-сокеты. Через них тоже можно передавать данные, и это сложнее заметить на глаз.
• Other — всё остальное, что не попало в основные категории.

Оставьте фильтр на Fetch/XHR и обновите страницу. Вы увидите все запросы к серверам. Теперь присмотритесь к каждому: куда идёт запрос, что в теле, какие заголовки.

Ищем подозрительные адреса

Самый очевидный признак утечки — запрос идёт не туда, куда должен. Сайт работает на example.com, а запрос уходит на some-tracker.xyz или cdn.unknown-service.com. Это не всегда утечка, но это всегда повод разобраться.

Как искать:

1. Откройте панель Network, нажмите на запрос, который кажется подозрительным.
2. В правой части откроются детали. Перейдите на вкладку Headers — там полный URL, метод, заголовки.
3. Посмотрите на Remote Address — это IP-адрес сервера, куда ушёл запрос. Если он не совпадает с IP вашего сервера или известных CDN, это подозрительно.
4. Вкладка Payload покажет, что именно отправлено в теле запроса. Ищите там email, телефон, токены, пароли, содержимое полей ввода.
5. Вкладка Response покажет, что пришло в ответ. Иногда утечка — это не только отправка, но и получение данных, которые не должны быть на клиенте.

Ищем конкретные данные в запросах

Допустим, вы знаете, что на странице есть поле с номером телефона, и хотите проверить, не отправляется ли оно куда-то помимо вашего сервера. В панели Network есть поиск — Ctrl+F (Cmd+F на Mac).

Введите в поиск значение, которое хотите найти: часть номера телефона, email, имя токена. Поиск пройдёт по всем запросам и ответам. Если значение найдётся в каком-то запросе к стороннему серверу — вы нашли утечку.

То же самое работает с регулярными выражениями. Введите паттерн типа \b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b — и найдёте все email-адреса, которые страница отправила в сеть.

Смотрим на заголовки: токены и куки

Данные утекают не только в теле запроса, но и в заголовках. Самые чувствительные:

• Cookie — если страница отправляет куки на сторонний сервер, это может быть кражей сессии.
• Authorization — токены Bearer, ключи API, которые передаются в заголовках.
• Referer — иногда в нём оказываются токены или идентификаторы из URL.
• Set-Cookie в ответе — если сторонний скрипт пытается установить куки, это может быть попыткой отслеживания или подмены сессии.

Проверяйте заголовки каждого подозрительного запроса. Если видите, что токен сессии или JWT отправляется на чужой домен — это серьёзная проблема.

Вкладка Application: что хранится на клиенте

Утечка — это не только передача данных, но и их неправильное хранение. Перейдите на вкладку Application (в некоторых версиях называется Storage).

Здесь вы видите:

• Local Storage и Session Storage — что там лежит. Ищите токены, персональные данные, содержимое форм. Если в localStorage лежит JWT или номер телефона — это плохо.
• Cookie — все куки, которые установлены для текущего домена. Обратите внимание на флаг HttpOnly — если его нет, куки доступны из JavaScript, и любой сторонний скрипт может их прочитать.
• IndexedDB — база данных браузера. Там тоже могут храниться данные, которые не должны быть доступны сторонним скриптам.

Если вы видите, что сторонний скрипт (например, виджет или пиксель аналитики) пишет в localStorage или читает куки — это потенциальная утечка.

Вкладка Sources: кто и что делает на странице

На вкладке Sources вы видите все загруженные скрипты. Это полезно, когда нашли подозрительный запрос и хотите понять, какой именно скрипт его отправил.

Откройте скрипт, найдите в нём строку, которая инициирует запрос (например, fetch, XMLHttpRequest, navigator.sendBeacon). Посмотрите, что именно передаётся и куда.

Также в Sources можно поставить точку останова (breakpoint) на отправку запроса и посмотреть, какие данные формируются в момент отправки. Это удобно, когда данные шифруются или кодируются перед отправкой — в запросе вы видите непонятную строку, а в отладчике — исходные данные.

Инструмент Coverage: находим неиспользуемый код

На первый взгляд бесполезная вкладка, но для поиска утечек она помогает. Откройте меню DevTools (три точки или Shift+?), выберите More tools → Coverage.

Нажмите на кнопку записи и обновите страницу. Coverage покажет, какой код каждого скрипта был выполнен, а какой — нет. Если вы видите, что сторонний скрипт загружается, но почти не используется — возможно, он был добавлен ранее и забыт. А может, он выполняет что-то в фоновом режиме, и вы этого не замечали.

Сравниваем: что отправляет страница

Допустим, вы хотите понять, какие данные страница отправляет при разных действиях: загрузка, клик по кнопке, отправка формы. В Network есть удобная функция сравнения.

1. Запишите запросы при обычной загрузке страницы.
2. Выполните действие (отправьте форму, кликните по кнопке).
3. Посмотрите, какие новые запросы появились.
4. Откройте каждый новый запрос и проверьте, что он отправляет.

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

Типичные сценарии утечек и где их искать

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

→ Network → Initiator

Симптом	Где искать	Что искать
Страница отправляет данные на неизвестный домен	Network → Fetch/XHR	URL запроса, тело запроса, Initiator
После авторизации появляются странные запросы	Network (сравнить до/после логина)	Новые запросы с токенами или данными пользователя
Сторонний скрипт читает куки или localStorage	Application → Cookies / Local Storage	Сторонние скрипты с доступом к хранилищу
Данные формы уходят не только на ваш сервер	Network → поиск по значению из формы	Значение поля в теле запроса к стороннему домену
Скрипт загружается с неожиданного источника	Цепочка: какой скрипт подтянул другой скрипт
Подозрительная активность после закрытия страницы	Network → WS, фильтр по sendBeacon	Запросы, которые отправляются при уходе со страницы

Частые ошибки при проверке

Когда люди начинают проверять сайт на утечки через DevTools, они часто наступают на одни и те же грабли:

• Смотрят только на свой домен. Фильтр по домену удобен, но он скрывает все сторонние запросы. А именно туда чаще всего утекают данные. Не фильтруйте по домену, когда ищете утечки.
• Проверяют только тело запроса. Данные могут передаваться в заголовках, в параметрах URL, в куках. Проверяйте всё.
• Не включают Preserve log. При переходе на другую страницу лог обнуляется, и вы теряете цепочку запросов. Всегда включайте эту опцию при проверке.
• Проверяют только начальную загрузку. Утечка может происходить при клике по кнопке, при отправке формы, при скролле, при уходе со страницы. Проверяйте все сценарии взаимодействия.
• Игнорируют веб-сокеты. Через WS тоже передаются данные, и это не видно в обычном списке Fetch/XHR. Переключайте фильтр на WS и проверяйте.
• Не проверяют ответы сервера. Утечка — это не только отправка, но и получение. Если сервер возвращает данные, которые не должны быть на клиенте (например, чужие токены), это тоже проблема.

Как проверять в зависимости от вашей ситуации

Если вы разработчик и хотите проверить свой сайт: пройдитесь по всем сценариям использования страницы — загрузка, авторизация, заполнение форм, оплата, выход из аккаунта. На каждом шаге смотрите Network и проверяйте, какие запросы уходят и что содержат. Особое внимание — моменты, когда на странице появляются сторонние скрипты: аналитика, виджеты, чат-боты, платёжные формы.

Если вы проверяете чужой сайт или интеграцию: сначала посмотрите, какие сторонние скрипты загружаются (вкладка Sources). Затем для каждого стороннего скрипта проверьте, какие запросы он инициирует (фильтр по Initiator в Network). Если сторонний скрипт отправляет данные на свой сервер — это не обязательно утечка, но это должно быть задокументировано и одобрено.

Если вы подозреваете конкретную утечку: используйте поиск по значению (Ctrl+F в Network). Введите данные, которые могли утечь, и проверьте, не отправляются ли они куда-то. Если данные кодируются перед отправкой, ищите по частичному совпадению или по структуре (например, формат JWT — три блока, разделённые точками).

Дополнительные инструменты внутри DevTools

Несколько менее очевидных возможностей, которые помогают при поиске утечек:

• Block request URL — правый клик по запросу в Network → Block request URL. Блокирует конкретный запрос. Полезно, чтобы проверить, что произойдёт, если сторонний скрипт не загрузится. Если страница работает нормально — возможно, этот скрипт можно убрать.
• Block request domain — то же самое, но блокирует весь домен. Если вы подозреваете, что все запросы к определённому домену лишние — заблокируйте и проверьте.
• Connection в заголовках запроса — показывает, используется ли keep-alive, какой протокол. Если данные отправляются по HTTP вместо HTTPS — это проблема безопасности.
• Preview и Response — показывают, что вернул сервер. Иногда в ответе оказываются данные, которые не должны быть на клиенте.

Что делать, когда нашли утечку

Если обнаружили, что данные уходят не туда:

1. Зафиксируйте факт. Скриншот запроса из DevTools, URL, тело запроса, Initiator. Это доказательство, которое можно показать разработчикам или администратору.
2. Определите источник. Какой скрипт инициирует запрос? Это ваш код, библиотека, сторонний сервис?
3. Проверьте, настроено ли это намеренно. Иногда данные отправляются на сторонний сервер специально — аналитика, платёжная система, CRM. Но если это не задокументировано и не одобрено — это утечка.
4. Устраните причину. Удалите или исправьте скрипт, который отправляет данные. Если это сторонний сервис — проверьте его настройки, возможно, нужно отключить передачу определённых данных.
5. Проверьте последствия. Если утечка касалась персональных данных пользователей, возможно, нужно уведомить их и соответствующие органы (в зависимости от законодательства).

Итог

Chrome DevTools — это первый и самый доступный инструмент для выявления утечек данных на сайтах. Он не требует установки дополнительного ПО, работает в любом современном браузере и даёт полную картину того, что происходит на сетевом уровне.

Главное — не ограничиваться просмотром запросов к своему домену. Смотрите на все запросы, проверяйте заголовки и тела, используйте поиск по значениям, включайте Preserve log и не забывайте про веб-сокеты. Если нашли подозрительный запрос — блокируйте его через DevTools и проверяйте, что изменилось.

Начните с простого: откройте Network, обновите страницу, отфильтруйте Fetch/XHR и просто просмотрите, куда уходят запросы. Уже на этом этапе можно найти самые очевидные проблемы.