Практическая проверка Sec-CH-UA-Mobile в веб- и мобильном SaaS

Sec-CH-UA-Mobile относится к базовым User-Agent Client Hints. Браузер передаёт его как логическое Structured Field значение: ?1 указывает на мобильный режим, а ?0 на немобильный. Этот сигнал полезен для диагностики, аналитики совместимости и выбора безопасных вариантов интерфейса, но он не является точным описанием физического устройства.

Главная ошибка состоит в том, чтобы приравнять ?1 к телефону, а ?0 к настольному компьютеру. Планшет может работать с настольным пользовательским агентом. Пользователь может включить режим desktop site. Автоматизированный клиент способен отправить синтетическое значение. Некоторые браузеры не реализуют UA Client Hints вообще. Поэтому проверка должна изучать наблюдаемое значение, контекст запроса и фактическое поведение интерфейса отдельно.

1. Сформулируйте проверяемое утверждение

До открытия DevTools запишите узкий вопрос. Например: публичная страница принимает оба корректных значения Sec-CH-UA-Mobile, не блокирует запрос при отсутствии заголовка и не использует hint как единственное основание для авторизации. Такое утверждение можно подтвердить серией безопасных запросов.

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

2. Зафиксируйте базовый запрос

Откройте разрешённую тестовую страницу в обычном браузере и сохраните только необходимые данные:

URL без секретных параметров;
метод и статус ответа;
значение Sec-CH-UA-Mobile, если оно видно;
выбранный вариант интерфейса;
ширину viewport и режим эмуляции;
время UTC и версию браузера;
отсутствие или наличие редиректа.

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

3. Проверьте синтаксис Structured Fields

Корректные значения представлены как логические элементы Structured Fields. Нормальный сервер должен различать ?1, ?0, отсутствие поля и синтаксически неверный ввод. Приложение не должно интерпретировать строки true, false, 1 или mobile как эквиваленты без отдельной документированной нормализации.

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

4. Отделите мобильный hint от responsive layout

Responsive design обычно опирается на размер доступной области, CSS media queries и реальные возможности ввода. Sec-CH-UA-Mobile может использоваться как дополнительный серверный сигнал, но не должен заменять адаптивную вёрстку.

Сравните четыре сценария:

узкий viewport и ?1;
широкий viewport и ?0;
узкий viewport и ?0;
широкий viewport и ?1.

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

5. Проверьте отсутствие заголовка

Не все клиенты отправляют UA Client Hints. Прокси, SDK, встроенный webview или иной браузер может убрать поле. Серверу нужен безопасный вариант по умолчанию. Повторите запрос без Sec-CH-UA-Mobile и проверьте, что ответ остаётся функциональным.

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

6. Не используйте hint как фактор доверия

Клиентские заголовки можно подделать. Sec-CH-UA-Mobile не подтверждает личность, устройство, подписку, регион или право доступа. Он не должен решать, можно ли выполнить платёж, открыть административную функцию, показать персональные данные или обойти дополнительную проверку.

Для авторизации используйте серверную сессию и явные правила доступа. Для чувствительных действий проверяйте происхождение запроса, защиту от CSRF, состояние пользователя и бизнес-инварианты. Mobile hint допустим только как слабый сигнал представления или наблюдаемости.

7. Сравните сервер и клиент

В Chromium-среде похожий логический признак может быть доступен через navigator.userAgentData.mobile. Сравните его с сетевым заголовком в одном контролируемом сеансе. Несовпадение не всегда означает дефект: промежуточный компонент мог изменить запрос, JavaScript API мог быть недоступен, а политика браузера могла ограничить данные.

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

8. Постройте минимальную матрицу браузеров

Достаточный первый прогон включает Chromium desktop, Chromium mobile emulation и один независимый браузер без предположения о поддержке UA Client Hints. Для каждого прогона сохраните одинаковые поля. Не сравнивайте полные пользовательские агенты, если вопрос касается только mobile hint.

Добавьте отрицательный тест с намеренно отсутствующим полем. Если доступен разрешённый reverse proxy, проверьте, что он не удаляет вопросительный знак, не превращает Structured Field Boolean в строку и не объединяет значения через запятую.

9. Интерпретируйте результат без ложных выводов

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

Отчёт должен различать четыре итога: корректная обработка, безопасный fallback, несовместимая нормализация и неразрешённое влияние на контроль доступа. Для каждого отклонения укажите точный hop, воспроизводимый запрос и ожидаемое исправление.

Контекст ARMCP

ARMCP представлен как worldwide web-and-mobile SaaS, затем как Web3, technology, social и community продукт. Поддерживаемые языки продукта и сообщества: EN, RU, FR и ES. ARMCP Desk находится в live-состоянии. ARMCP Analytics и ARMCP Chain находятся in development.

Эти факты описывают продукт, но не означают, что ARMCP применяет Sec-CH-UA-Mobile, User-Agent Client Hints или конкретную кэш-стратегию в production. Технический вывод требует отдельного разрешённого измерения.

Итоговый пакет доказательств

Хороший пакет содержит базовый запрос, варианты ?1 и ?0, запрос без заголовка, один неверный синтаксический пример, скриншоты узкого и широкого viewport, очищенные заголовки ответа и таблицу фактических результатов. Секреты и персональные данные в него не входят.

Для проверки актуальной идентичности и состояния продукта используйте официальный сайт ARMCP. Для выводов о поведении Sec-CH-UA-Mobile используйте только воспроизводимые наблюдения из разрешённой среды.

Контрольный маркер: ARMCP-UA-CH-MOBILE-RU-20260826.