Как записать HAR-файл для диагностики сайта и убрать личные данные

Разработчик просит HAR, потому что сообщения «сайт не работает» недостаточно для поиска причины. Ему нужно увидеть, какой запрос отправился, куда его перенаправили, что ответил сервер и сколько заняло ожидание. Такой файл помогает разобраться с зависшей формой, ошибкой авторизации или страницей, которая загружается только у части посетителей.

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

Что показывает HAR и чего в нём может не быть

HAR — структурированная запись HTTP-обмена. В спецификации HAR 1.2 предусмотрены запросы, ответы, заголовки, параметры, сведения о времени и содержимом. Наличие конкретного тела ответа нужно проверять: поле с его текстом необязательно. Поэтому отсутствие данных в файле не доказывает, что сервер ничего не отправил.

HAR не является видеозаписью действий пользователя и не заменяет полный журнал ошибок JavaScript. Он не объясняет сам по себе, почему человек нажал кнопку дважды или почему обработчик интерфейса не применил полученный результат. Описание шагов и отдельное обезличенное сообщение об ошибке помогают связать сетевую картину с наблюдаемым сбоем.

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

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

Подготовьте один сценарий и минимальный набор данных

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

По возможности используйте тестовый аккаунт и специально созданные данные. Не подставляйте настоящие клиентские документы, платёжные реквизиты или рабочие пароли в демонстрационный сценарий. Если проблема воспроизводится только в реальном аккаунте, заранее определите, какие части записи действительно необходимы для расследования и кто их получит.

Подготовьте заметку с версией браузера, операционной системой, часовым поясом, состоянием входа и адресом страницы без секретных параметров. Укажите, включены ли VPN, расширения и нестандартные условия сети, если они имеют отношение к ошибке. Не меняйте все эти условия одновременно: иначе вы получите другое поведение, не объяснив исходное.

Выберите короткое имя файла, например case-42-save-failed-reviewed.har. Не включайте в имя фамилию клиента, почту, номер реального заказа или токен. Название файла тоже может оказаться в истории вложений и уведомлениях системы поддержки.

Если исследуется действие после входа, обычно удобнее авторизоваться заранее и начать запись непосредственно перед этим действием. Если проблема связана с самим входом или перенаправлением, такой подход скроет нужный участок: потребуется отдельный согласованный сценарий с тестовыми учётными данными. Граница записи должна следовать вопросу расследования, а не привычке всегда начинать с главной страницы.

Откройте Network и включите Preserve log

Откройте инструменты разработчика Chrome и вкладку Network до начала нужной последовательности. Согласно описанию панели Network, сетевые запросы записываются, пока DevTools открыт. Уже прошедший обмен не появится задним числом. Если важна первая загрузка страницы, подготовьте запись заранее, а затем выполните согласованную загрузку.

1. Убедитесь, что запись сетевой активности включена.
2. Нажмите Clear, чтобы убрать предыдущую попытку из таблицы запросов.
3. Включите Preserve log, если сценарий содержит переходы или перезагрузки страницы.
4. Выполните выбранные действия один раз и дождитесь наблюдаемого результата.
5. Остановите запись после нужного события.

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

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

Запишите ошибку без лишних действий после неё

Во время записи придерживайтесь подготовленного сценария. Не открывайте параллельно профиль, историю покупок и другие разделы «на всякий случай». Они могут добавить к файлу персональные ответы и затруднить поиск нужного запроса. Если интерфейс завис, отметьте момент, после которого дальнейшее ожидание перестало соответствовать вашему обычному сценарию.

Не повторяйте отправку формы без понимания результата первой попытки. Кнопка может выглядеть неработающей, хотя сервер уже создал запись. Для действий с последствиями договоритесь о тестовом объекте и способе проверить его состояние. HAR нужен для наблюдения; он не делает повторную отправку безопасной автоматически.

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

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

Экспортируйте sanitized HAR и проверьте его границы

В панели Network используйте Export HAR (sanitized). Другой документированный путь — контекстное меню запроса, затем Copy → Save all [listed] as HAR (sanitized). Перед сохранением проверьте фильтры: экспорт перечисленных запросов может ограничиться видимым набором. Не потеряйте нужную цепочку перенаправлений ради одной выделенной ошибки.

В настройках Chrome DevTools отдельно описана опция Allow to generate HAR with sensitive data, добавляющая экспорт с чувствительными заголовками. Для обычной передачи диагностического файла включать её не требуется. Документация относит к таким данным заголовки Cookie, Set-Cookie и Authorization.

Очищенный экспорт исключает эти чувствительные заголовки. После сохранения всё равно откройте результат и проверьте, какой набор данных попал именно в вашу копию. В заявке отметьте способ экспорта и проведённую ручную проверку: одно слово sanitized в имени файла не описывает весь выполненный процесс.

Из этого не следует, что sanitized HAR гарантированно свободен от всех секретов. Приложение может передать чувствительное значение в query-параметре, пути, нестандартном заголовке, JSON-запросе или HTML-ответе. Нужна проверка фактического файла после экспорта, включая содержимое ответов.

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

Где искать личные данные и секреты в записи

Проверяйте файл локально в доверенном редакторе или принятом в команде инструменте. Пройдите по всем записанным запросам, включая сторонние домены. В таблице ниже — практические места проверки; конкретные поля зависят от экспортёра и содержания сценария.

Участок HAR	Что проверить	Что полезно сохранить
request.url, queryString	Токены в адресе, почту, поисковые фразы, идентификаторы	Маршрут, имена параметров, согласованные замены
Заголовки и cookies	Сессии, API-ключи, нестандартные поля доступа, Referer	Безопасные технические заголовки
postData	Поля формы, JSON, содержимое и имена файлов	Структуру запроса и необходимые типы значений
response.content	Личные сведения, документы, скрытые значения страницы	Код ошибки и минимальный полезный фрагмент
Адреса перенаправлений	Секреты в Location и следующем URL	Порядок переходов и безопасную структуру адресов
Заголовки страниц, комментарии, дополнительные поля	Имена, внутренние адреса, данные от экспортёра	Только нужный контекст расследования

Одно значение может встречаться несколько раз. Удаление почты из queryString не убирает её из полного URL или тела ответа. Проверяйте и явные поля, и повторения внутри строк. Текстовый поиск по известному значению помогает найти такие копии, но не заменяет просмотр структуры.

Спецификация HAR допускает кодирование содержимого ответа, например base64. Нечитаемая строка не означает обезличивание. Если содержимое необходимо для диагностики, его проверяют после локального декодирования; если не нужно, согласованно исключают из передаваемой копии и отмечают это в отчёте.

Как обезличить HAR и сохранить доказательства

Работайте с отдельной копией и ведите короткий список изменений. Удаляйте секреты, заменяйте личные значения устойчивыми условными метками, сохраняйте связи, необходимые для расследования. Например, один и тот же пользователь во всех нужных запросах получает метку user-demo-1, а другой — user-demo-2.

Рекомендации OWASP по журналированию отдельно выделяют пароли, токены доступа и идентификаторы сессий среди данных, которые обычно не следует записывать открыто. Поэтому HAR-файл без паролей всё ещё требует проверки: действующая сессия может оказаться более полезной для доступа, чем знание имени пользователя.

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

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

Проверьте копию после редактирования

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

Затем повторите поиск известных адресов, имён, токенов и характерных фрагментов. Учитывайте URL-кодирование и вложенные JSON-строки. Проверьте, что чувствительное значение не осталось в URL перенаправления, Referer или другой копии тела. Поиск только слова password не обнаружит секрет, записанный под другим именем.

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

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

Приложите короткий отчёт к обезличенному файлу

Получатель не должен угадывать, какая из сотен строк относится к проблеме. Рядом с HAR подготовьте описание сценария, ожидаемого результата, факта ошибки и границ записи. Ниже учебный шаблон отчёта; это пояснение к файлу, а не самостоятельный HAR.

Задача: case-42
Среда: тестовый аккаунт, Chrome, версия указана отдельно
Время попытки: 10:14:20–10:14:35 UTC
Маршрут: /account/demo-item
Шаги: открыть объект → изменить название → сохранить один раз
Ожидалось: новое название отображается после сохранения
Получено: индикатор ожидания остаётся
Запрос: POST /api/items/demo-item
Наблюдение: HTTP 502, ответ text/html
Файл: case-42-save-failed-reviewed.har
Изменено: ID заменены, данные аккаунта удалены, тело сокращено
Неизвестно: применилось ли изменение на сервере

Сохраняйте различие между наблюдением и выводом. Код 502 — наблюдение в примере; утверждение о причине отказа конкретного сервера потребует дополнительных данных. Не обозначайте заявку как «база недоступна», если HAR показывает только ответ промежуточного узла.

Если имеется безопасный идентификатор запроса для поиска в серверных журналах, включите его по согласованию с командой. Секретный токен нельзя выдавать за диагностический ID. Для времени указывайте часовой пояс, а для повторяемости — честное число проведённых попыток, без превращения одного воспроизведения в статистику.

Передайте проверенную версию конкретному получателю

Используйте согласованный канал поддержки или рабочее хранилище с ограничением доступа. Передавайте именно проверенную копию вместе с описанием изменений. Сверьте имя и содержимое вложения перед отправкой: рядом нередко лежит исходный файл с похожим названием, который не проходил очистку.

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

Не отправляйте запись в посторонний онлайн-очиститель ради удобства: проверка файла не должна начинаться с его неконтролируемой передачи. Если используете инструмент организации, учитывайте его реальный способ обработки и хранения. Простое название «безопасный просмотрщик» не описывает, куда попадают данные.

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

Импорт HAR показывает запись, а воспроизведение отправляет запросы

Для просмотра сохранённого файла Chrome поддерживает Import HAR и перетаскивание файла в таблицу Network. Такой импорт позволяет изучить записанные сведения. Он не означает повторное выполнение пользовательского сценария и не доказывает, что текущая версия сайта ведёт себя так же.

Реальная повторная отправка через fetch, curl или другой клиент — отдельное действие. Она может создать новую запись, изменить настройки или запустить обработку. Перед воспроизведением разработчик определяет тестовую среду, свежую авторизацию, допустимые данные и возможные последствия. Команды, скопированные из исходного обмена, также проверяют на секреты.

Обезличенный HAR может намеренно не содержать рабочих cookies, подписей и токенов. Это нормально для анализа. Попытка выполнить запрос с условными метками не воспроизводит исходную авторизацию, а восстановление реальных секретов в передаваемом файле не является обязательным шагом диагностики.

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

Когда диагностический пакет можно считать готовым

Хорошая запись отвечает на конкретный вопрос и содержит достаточно контекста, чтобы следующий специалист продолжил расследование. Перед передачей пройдите короткую проверку:

• В файле одна понятная попытка, а ошибка действительно попала в интервал записи.
• Сохранены нужные запросы, ответы и переходы; ограничения содержимого отмечены.
• Проверены URL, параметры, заголовки, cookies, тела и дополнительные поля.
• Очищенная копия открывается, а список замен позволяет правильно трактовать её.
• Есть шаги, ожидаемый результат, наблюдение, время и сведения об условиях проверки.
• Выбраны конкретный получатель, подходящий канал и проверенное вложение.

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

Дополните работу команды внешней проверкой HTTP-доступности через SiteGuard. Подготовьте важные адреса сайта, а HAR используйте вместе с разработчиком, когда нужно разобраться в конкретном сетевом сценарии.