App 內建瀏覽器揭密：微信、TikTok 裡的 WebView

在微信、TikTok、Instagram 或 Zalo 裡點開一個連結，打開的頁面看起來像瀏覽器——有網址列、返回按鈕、分享圖示——但它並不是你設定的預設瀏覽器。這是一個內建瀏覽器：頁面渲染在宿主 App 內部，使用的是這個 App 自己嵌入並控制的 WebView。這個區別很容易被忽略，但影響比看起來的還大。

核心重點

• 在社群 App 內點開的連結，會在嵌入式 WebView（Android 系統 WebView / iOS 的 WKWebView）中渲染，而不是你的預設瀏覽器——這是宿主 App 自己控制的獨立元件。
• App 內建的 WebView 可以向它渲染的頁面注入自己的 JavaScript，而且通常無法使用你預設瀏覽器裡的擴充功能、已儲存的密碼或隱私設定。
• 在 iOS 上，蘋果要求所有 iOS 瀏覽器都以 WebKit 為基礎，所以每個 WebView 也都是 WebKit 核心；在 Android 上，WebView 以 Chromium 為基礎，其版本與嵌入它的任何 App 是分開更新的。
• 內建瀏覽器會洩露自己的身分：Android user-agent 裡的 wv 標記，或是 iOS 上獨立的 WKWebView 環境——這些正是偵測工具早已在核查的訊號。
• 涉及登入、付款、銀行業務等敏感操作時，請點選選單裡的「用瀏覽器開啟」選項，而不要留在 App 內建的檢視畫面裡。

WebView 究竟是什麼？

WebView 是作業系統提供的一個元件，讓任何 App 都能渲染網頁內容，而不必從零打造自己的瀏覽器引擎。在 Android 上，它就叫 Android 系統 WebView——一個系統層級的 App，透過 Play 商店獨立更新，Chrome、TikTok、微信以及成千上萬個其他 App 都嵌入了它。在 iOS 上，對應的元件是蘋果 WebKit 框架提供的 WKWebView，另外還有一種更輕量的情況是 SFSafariViewController——它會共用 Safari 的 Cookie 與已儲存的登入狀態。

這兩個 iOS 選項之間的差異對追蹤來說很重要：WKWebView 擁有自己獨立、Cookie 隔離的儲存環境，因此透過它開啟的工作階段看不到你既有的 Safari 瀏覽狀態。相較之下，SFSafariViewController 會共用 Safari 的工作階段——你在其他地方已登入的帳號，在這裡也會維持登入。大多數社群 App 的內建連結預覽用的都是純粹的 WKWebView，這正是為什麼在 TikTok 或 Instagram 裡打開一個連結，即使你在其他地方早已登入，往往還是要你重新登入一次。

為什麼這很重要：宿主 App 能做什麼、不能做什麼

因為宿主 App 控制著 WebView 執行個體，它對頁面的控制權，比第三方在一般瀏覽器分頁裡所能擁有的還要大得多。宿主 App 可以向它渲染的每個頁面注入自己的 JavaScript——常見用途是浮動分享按鈕之類的介面元素，但同樣的機制同樣可以用來追蹤你在頁面裡的捲動深度、點擊或表單輸入，即便這些頁面本不該被 App 看到內部細節。這一切都不需要突破任何瀏覽器安全模型——這本來就是嵌入 WebView 被設計出來允許嵌入方做的事。

對你來說，實際的缺點很具體：

• 沒有擴充功能。 你在真實瀏覽器裡安裝的廣告攔截器、密碼管理器和隱私擴充功能，都不會在 App 的 WebView 裡運作。
• 通常沒有已儲存的登入狀態。 一個新建的 WKWebView 或 Android WebView 執行個體通常是空儲存空間啟動的，所以你真實瀏覽器裡的自動填入和已儲存密碼派不上用場。
• 沒有預設瀏覽器的隱私設定。 如果你已經強化過真實瀏覽器——封鎖第三方 Cookie、關閉容易被指紋識別利用的 API——這些設定都不會帶入宿主 App 的 WebView。
• 成為宿主 App 的追蹤管道。 你在內建瀏覽器裡做的一切，除了目的地網站本身能看到之外，宿主 App 也能看到。

這並非某個 App 特有的行為——這就是 WebView 的設計方式，微信、TikTok、Instagram、X 以及大多數帶內建連結預覽的 App 都是如此。

偵測角度：WebView 如何洩露自己的行蹤

WebView 對它渲染的網站來說並非不可見。在 Android 上，嵌入式 WebView 通常會在其 user-agent 字串末端附加一個 wv 標記——例如 Mozilla/5.0 (Linux; Android 14) ... Chrome/124.0.0.0 Mobile Safari/537.36 wv——分析工具和偵測腳本正是靠這個標記，一眼分辨出「真正的 Chrome」流量與某個 App 的內建瀏覽器流量。Chrome 官方的 WebView 文件說明了這個元件如何獨立於任何嵌入它的 App 而單獨更新與版本化，這也是為什麼同一支手機上，WebView 回報的 Chromium 版本，可能落後於（或領先於）手機上「真正的」Chrome 版本。

在 iOS 上，user-agent 裡沒有類似 wv 的標記——WKWebView 回報的 UA 與真正的 Safari 幾乎一模一樣——但執行環境仍然存在差異，指紋識別與核心檢測工具可以偵測到這些差異：儲存分區行為、是否存在完整的瀏覽器介面外殼，以及蘋果在 Safari 本體與嵌入式 WebView 之間不同的 API 授權策略。蘋果自己的追蹤防護文件說明了 WebKit 在這些不同瀏覽環境之間套用的儲存分區規則，這也是為什麼 WebView 工作階段無法悄悄借用你已登入的 Safari 狀態。

更廣泛地說，user-agent 偽裝偵測技術——核查請求標頭順序、Client Hints 以及 JavaScript 引擎行為是否與聲稱的瀏覽器相符——同樣適用於分辨內建 WebView 和它所模仿的瀏覽器，因為 WebView 底層引擎的細微行為，往往對不上宿主 App 偽裝出來的身分。

Android WebView 與 iOS WKWebView 對照

	Android WebView	iOS WKWebView
引擎	Chromium（Blink）	WebKit
版本更新	透過 Play 商店獨立更新	與 iOS 版本綁定
UA 標記	附加 wv 標記	無獨立標記
Cookie / 工作階段隔離	取決於宿主 App 的設定	預設隔離（不同於 SFSafariViewController）
擴充功能 / 已儲存密碼	不可用	不可用

引擎這一層的故事，其實呼應了一個更廣泛的平台規則：包括 Chrome、Firefox、Edge 在內，每一個 iOS 瀏覽器都被要求以 WebKit 為基礎運作，所以 iOS 上的內建 WebView，執行的渲染引擎永遠和 Safari 一樣，差別只在沙盒隔離方式不同。Android 則沒有這樣的強制規定，這也是為什麼 Android WebView 按自己的節奏跟著 Chromium 的發布週期走。

如何切換回你的真實瀏覽器

大多數帶內建瀏覽器的 App 都提供一個「逃生艙」，通常藏在內建畫面右上角的選單圖示裡（三個點，或是帶箭頭的分享圖示）——找找「用瀏覽器開啟」「用 Safari 開啟」或「用 Chrome 開啟」這類選項。在輸入密碼、付款資訊或任何其他敏感內容之前先這麼做，能讓你回到真正的預設瀏覽器：你儲存的登入狀態、你的廣告攔截器，以及你已經設定好的各種隱私強化措施。

檢查你正在瀏覽的環境

透過 BrowserInsight 的核心檢測與指紋檢測，你可以確切看出正在渲染目前頁面的是完整瀏覽器還是嵌入式 WebView。在某個社群 App 的內建瀏覽器裡執行一次，再在你的正常瀏覽器裡執行一次，比較一下——引擎、版本回報行為和 WebView 標記，往往會講出明顯不同的故事。