Встроенные браузеры: что такое WebView в WeChat и TikTok

Откройте ссылку в WeChat, TikTok, Instagram или Zalo — и страница, которая появится, будет выглядеть как браузер: адресная строка, кнопка «назад», значок «поделиться». Но это не тот браузер, что стоит у вас по умолчанию. Это встроенный браузер: страница рендерится прямо внутри самого приложения-хоста, через WebView, который это приложение встраивает и контролирует. Разницу легко упустить, а последствия у неё серьёзнее, чем кажется.

Ключевые выводы

• Ссылки, открытые внутри соцсетей, рендерятся во встроенном WebView (Android System WebView / WKWebView на iOS), а не в вашем браузере по умолчанию — это отдельный компонент, который контролирует само приложение.
• Встроенный WebView может внедрять собственный JavaScript в страницу, которую он рендерит, и обычно не может использовать расширения, сохранённые пароли или настройки приватности вашего основного браузера.
• На iOS каждый WebView построен на WebKit, поскольку Apple требует этого от всех iOS-браузеров; на Android WebView построен на Chromium и версионируется отдельно от любого приложения, которое его встраивает.
• Встроенный браузер выдаёт себя сам: токен wv в user-agent на Android или отдельный контекст WKWebView на iOS — сигналы, которые уже проверяют инструменты обнаружения.
• Для всего чувствительного — входа в аккаунт, оплаты, банкинга — открывайте страницу через пункт меню «Открыть в браузере», а не оставайтесь во встроенном окне приложения.

Что такое WebView

WebView — это компонент операционной системы, который позволяет любому приложению рендерить веб-контент, не создавая собственный браузерный движок с нуля. На Android он так и называется — Android System WebView: системное приложение, обновляемое независимо через Play Store, которое встраивают Chrome, TikTok, WeChat и тысячи других приложений. На iOS аналогичный компонент — WKWebView из фреймворка Apple WebKit, а также более лёгкий вариант — SFSafariViewController, который делится с Safari куками и сохранёнными логинами.

Разница между этими двумя вариантами на iOS важна для слежки: WKWebView получает собственное изолированное хранилище с отдельными куками, поэтому сессия, открытая через него, не видит вашу существующую историю в Safari. SFSafariViewController, напротив, делится сессией Safari — вы остаётесь залогинены на сайтах, где уже вошли в аккаунт. Большинство соцсетей используют для превью ссылок именно голый WKWebView, поэтому ссылка, открытая в TikTok или Instagram, часто заставляет вас войти заново, даже если вы уже везде залогинены.

Почему это важно: что может (и не может) приложение-хост

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

Практические минусы для вас вполне конкретны:

• Нет расширений. Блокировщики рекламы, менеджеры паролей и расширения для приватности, установленные в вашем настоящем браузере, не работают внутри WebView приложения.
• Обычно нет сохранённых логинов. Голый WKWebView или свежий экземпляр Android WebView обычно запускается с пустым хранилищем, так что автозаполнение и сохранённые пароли из вашего настоящего браузера недоступны.
• Нет настроек приватности браузера по умолчанию. Если вы усилили защиту своего настоящего браузера — блокировали сторонние куки, отключили API, уязвимые к фингерпринтингу, — ничто из этого не переносится в WebView приложения-хоста.
• Канал слежки для приложения-хоста. Всё, что вы делаете во встроенном браузере, видно не только целевому сайту, но и приложению, которое его встроило.

Это не особенность какого-то одного приложения — так устроен WebView по замыслу в WeChat, TikTok, Instagram, X и большинстве других приложений со встроенным предпросмотром ссылок.

Угол обнаружения: как WebView себя выдаёт

WebView не невидим для сайтов, которые он рендерит. На Android встроенный WebView обычно добавляет токен wv в конец строки user-agent — например, Mozilla/5.0 (Linux; Android 14) ... Chrome/124.0.0.0 Mobile Safari/537.36 wv — именно по этому токену аналитика и скрипты обнаружения с первого взгляда отличают трафик «настоящего Chrome» от встроенного браузера приложения. Официальная документация Chrome по WebView описывает, как этот компонент версионируется и обновляется независимо от любого приложения, которое его встраивает, — поэтому на одном и том же телефоне версия Chromium, которую сообщает WebView, может отставать от версии «настоящего» Chrome на устройстве (или опережать её).

На iOS аналогичной метки wv в user-agent нет — WKWebView сообщает UA, почти неотличимый от настоящего Safari, — но контекст выполнения всё равно отличается способами, которые могут проверить инструменты фингерпринтинга и проверки ядра браузера: поведение разделения хранилища, наличие (или отсутствие) полноценной оболочки браузера и доступность API, которую Apple по-разному ограничивает между самим Safari и встроенным WebView. Документация Apple по защите от слежки описывает правила разделения хранилища, которые WebKit применяет к этим разным контекстам просмотра, — отчасти поэтому сессия WebView не может незаметно воспользоваться вашим залогиненным состоянием в Safari.

В более широком смысле техники обнаружения подмены user-agent — проверка порядка заголовков, client hints и поведения движка JavaScript на соответствие заявленному браузеру — точно так же применимы к тому, чтобы отличить встроенный WebView от браузера, который он имитирует, поскольку особенности движка WebView под капотом не всегда совпадают с маскировкой приложения-хоста.

Android WebView и iOS WKWebView рядом

История с движком отражает более широкое правило платформы: каждый браузер на iOS — включая Chrome, Firefox и Edge — обязан работать на WebKit, так что встроенный WebView на iOS никогда не использует другой движок рендеринга, чем Safari, — разница только в изоляции песочницы. У Android такого требования нет, поэтому Android WebView следует собственному графику релизов Chromium.

Как перейти в настоящий браузер

Большинство приложений со встроенным браузером предлагают «аварийный выход», обычно спрятанный в значке меню в углу встроенного окна (три точки или значок «поделиться» со стрелкой) — ищите пункты вроде «Открыть в браузере», «Открыть в Safari» или «Открыть в Chrome». Сделав это перед вводом пароля, платёжных данных или чего-то ещё чувствительного, вы возвращаетесь в свой настоящий браузер по умолчанию: к сохранённым логинам, блокировщику рекламы и любым настройкам приватности, которые вы уже настроили.

Проверьте, в каком контексте вы находитесь

С помощью проверки ядра браузера и проверки отпечатка от BrowserInsight можно точно увидеть, что рендерит текущую страницу — полноценный браузер или встроенный WebView. Запустите проверку внутри встроенного браузера какого-нибудь приложения, а затем в своём обычном браузере, и сравните: движок, поведение при сообщении версии и метки WebView часто рассказывают заметно разные истории.