移动端网站的安全问题比PC端更复杂，不是因为攻击技术更高深，而是因为移动端的运行环境天然碎片化。同一个漏洞在iOS的Safari上可能完全无法利用，在安卓某些WebView里却能直接读取通讯录。检测移动端漏洞，必须把浏览器内核、系统版本、WebView组件、混合应用框架这几个变量同时纳入考量，否则漏报率会高得离谱。

先说检测。移动端漏洞检测不能只依赖桌面端的扫描器，很多针对移动端的攻击面在桌面浏览器里根本不会触发。比如Intent Scheme劫持、WebView的addJavascriptInterface远程代码执行、iOS的Universal Link劫持，这些漏洞只在移动环境里成立。检测的第一步是确认你的站点在移动端到底以什么形态运行：是纯浏览器访问，还是被App内嵌WebView加载，还是通过小程序WebView渲染。形态不同，攻击面完全不同。

纯移动浏览器场景下，最容易被忽略的是混合内容与证书校验问题。很多站点在PC上全站HTTPS，但移动端为了兼容老旧安卓机，会保留HTTP资源引用。攻击者在公共WiFi下做中间人，注入一段针对移动端UA的脚本，就能窃取表单数据。检测方法很简单：用安卓4.4以下版本的设备或模拟器访问站点，抓包看是否有HTTP请求发出。同时检查HSTS头是否在所有子域名下都生效，包括移动端专用的m.子域名。

WebView场景下的检测要复杂得多。安卓WebView的漏洞历史上多次出现，最典型的是通过addJavascriptInterface暴露Java对象给JS调用。如果你的App内嵌了网页，并且调用了这个方法，攻击者只要能往页面里注入JS，就能直接调用Java层的敏感方法。检测时要审计App代码里所有addJavascriptInterface的调用点，确认暴露的对象没有危险方法，同时检查WebView是否设置了setAllowFileAccess(false)和setAllowUniversalAccessFromFileURLs(false)。这两个设置不关，本地文件读取和跨域攻击的风险会成倍增加。

iOS端的WebView检测重点在WKWebView和UIWebView的差异。UIWebView已经废弃但仍有大量App在用，它无法精细控制JS与原生交互的权限。如果你的App还在用UIWebView加载远程页面，建议直接列为高危项。WKWebView相对安全，但要注意自定义URL Scheme的处理逻辑，攻击者可以构造特殊链接触发App内部跳转，绕过某些权限校验。

还有一个经常被忽视的检测点：移动端UA嗅探逻辑本身可能成为漏洞入口。很多站点根据UA字符串判断是否跳转到移动版页面，攻击者可以伪造UA让服务端返回不同的响应内容。如果移动版页面在安全策略上比PC版宽松，比如关闭了某些安全头、或者暴露了不同的API接口，这就形成了一个逻辑漏洞。检测时要对比同一URL在不同UA下的响应头差异，特别是CSP、X-Frame-Options、X-Content-Type-Options这些安全头的配置是否一致。

专项防护方面，第一项要处理的是点击劫持在移动端的变种。移动端屏幕小，用户更容易误触。攻击者利用透明iframe覆盖在按钮上，诱导用户点击执行恶意操作。单纯设置X-Frame-Options为DENY在部分移动浏览器上会被忽略，更可靠的做法是配合CSP的frame-ancestors指令，并且在页面加载时用JS检测window.top是否等于window.self，不等则跳转或提示。对于WebView场景，还要在App层设置WebView的setJavaScriptCanOpenWindowsAutomatically为false，防止弹窗类攻击。

第二项防护是针对移动端特有的协议劫持。安卓的Intent Scheme可以让网页通过intent://链接唤起App组件，如果App对传入的参数没有严格校验，攻击者可以构造恶意intent触发敏感操作。防护措施是在App的AndroidManifest.xml中，对所有导出的组件设置android:exported="false"，必须导出的组件要校验intent的来源和参数。同时，在WebView中拦截intent://开头的URL，只允许白名单内的scheme通过。

第三项是数据存储层的防护。移动端浏览器和WebView的本地存储机制比桌面端更容易被物理接触攻击。如果用户手机丢失或被盗，攻击者可以通过USB调试或备份文件提取WebView的本地数据库。敏感数据如token、用户信息不应存储在localStorage或IndexedDB中，应该使用App层的加密存储，或者设置较短的会话过期时间。对于必须缓存的非敏感数据，也要在服务端设置Cache-Control: no-store，减少本地残留。

第四项防护是移动端特有的输入安全问题。移动端键盘输入时，部分安卓输入法会缓存输入内容并上传到云端，这属于不可控的第三方风险。对于密码、验证码等高敏感输入框，建议使用自定义键盘或至少设置autocomplete="off"和autocorrect="off"。同时，移动端页面要防止输入框被第三方键盘截屏，安卓上可以通过设置FLAG_SECURE标志阻止截屏，iOS上在App层设置UITextField的secureTextEntry属性。

第五项是API接口的移动端专项加固。移动端页面通常通过API与后端交互，这些API在移动端更容易被逆向分析。攻击者可以通过抓包工具获取API地址和参数结构，然后批量尝试越权访问。防护上要做三件事：一是对所有API启用请求签名机制，签名参数包含时间戳和随机数，防止重放；二是对移动端UA的请求做频率限制，阈值比PC端更严格；三是在API响应中不要返回多余字段，移动端页面往往只需要部分数据，返回完整对象结构会泄露敏感信息。

第六项防护涉及混合应用框架的安全配置。如果你的移动端站点使用了React Native、Flutter或Cordova这类框架，要特别注意框架本身的配置漏洞。Cordova的config.xml中如果设置了过宽的访问源，比如允许访问所有外部域名，攻击者注入的脚本就能读取原生插件的能力。React Native的调试模式在生产环境必须关闭，否则攻击者可以通过调试端口执行任意JS。Flutter相对安全，但要注意其WebView插件的配置，默认情况下Flutter的WebView插件不会启用JS，但很多开发者为了方便会手动开启，开启后就要按纯WebView的标准做防护。

检测工具方面，移动端不能只用Burp Suite这类桌面代理。建议配合使用专门针对移动端的测试工具，比如MobSF做APK静态分析，Frida做动态插桩，Objection做运行时安全评估。对于纯网页场景，可以用Chrome DevTools的设备模拟模式做初步检测，但最终必须用真机验证，因为模拟器无法完全还原WebView的真实行为。特别是涉及触摸事件、传感器调用、系统级弹窗的场景，真机测试是唯一可靠的方式。

最后要强调一个容易被忽略的点：移动端的安全策略更新频率必须比PC端更高。移动操作系统和WebView组件的更新节奏快，新漏洞的利用代码往往在补丁发布后几小时内就出现。建议建立移动端安全基线清单，每两周复查一次，重点跟踪安卓WebView和iOS WKWebView的CVE公告。同时，在服务端对移动端流量做实时监控，一旦发现异常的UA分布、异常的API调用序列、或者来自同一设备的大量请求，立即触发告警并临时封禁。

移动端漏洞检测和防护的核心逻辑，是把移动环境当成一个独立的安全域来对待，而不是PC端安全策略的简单延伸。只有针对移动端的运行机制做专项设计和持续检测，才能把风险控制在可接受的范围内。