企业官网建设流程全解析

你有没有遇到过这种情况：应用刚上线没多久，市场上就出现了带广告的盗版包；或者测试环境的接口地址被人扫出来，用户手机号被挨个拖走。这些问题的根源，往往不在服务器，而在 Android 客户端本身。做 Android 开发这些年，我见过太多项目把安全当成上线前的一次性合规动作，草草加个混淆就交付，结果出问题时才发现处处是坑。

这篇文章围绕 Android 开发里的常见安全问题，梳理了一份可以落地的加固参考。内容包括：安全风险地图怎么画、数据存储层怎么加密、网络传输和 WebView 防线怎么搭、组件导出和 Intent 攻击怎么收口、逆向对抗怎么做，以及一份能贴在版本发布流程里的自查清单。适合正在做 Android 应用、打算对存量项目做安全改造，或者刚接手一个没人维护的老项目的开发者。我不堆概念，尽量按照“这个问题长什么样、为什么会产生、怎么解决”来写。

1. 先在心里面建立一张安全风险地图

1.1 Android 安全为什么难做

Android 的安全难，不是说系统没有防护机制，而是它的防护边界和开发者的预期经常错位。

一是碎片化。不同版本的系统权限模型不一样，个别厂商定制 ROM 还会改掉一些默认行为。你在 Android 13 上测试没问题，不代表 Android 8 的真机上同样安全。二是应用运行环境不可控。你的 App 会被安装到各种奇奇怪怪的设备上，有些设备用户自己 root 过，恶意软件也能拿到更高权限。三是攻击面太多。客户端代码、本地数据、网络传输、组件交互、第三方 SDK，任何一条链路存在漏洞，都可能成为突破口。

很多团队的误解是：只要后端接口做了鉴权，客户端就可以松一点。可实际情况是，客户端是攻击者最容易接触到的部分。APK 拿回去反编译、脱壳、hook，运行时的数据流和协议逻辑都会被分析。安全不能指望“攻击者看不懂”，要假设“攻击者看得懂，并且会尝试利用”。

1.2 容易被忽视的进攻路径

我习惯把攻击路径分成四类来排查，这样思维不容易乱。

第一是静态逆向。攻击者用工具解包 APK，读 AndroidManifest，看 Java/Kotlin 代码，或者直接翻资源文件。如果 App 没有做混淆，里面 Redis 地址、OSS 密钥、加密盐值写得清清楚楚；如果字符串没有处理，直接搜关键词就能定位到核心逻辑。我之前接手过一个老项目，硬编码的云存储密钥直接躺在 BuildConfig 里，打包后任何拿到 APK 的人都能看到。

第二是动态调试。攻击者在模拟器或者 root 过的真机上运行你的 App，hook 关键函数，dump 内存里的对象，篡改返回值。一些商业 App 会做防调试和反 Frida 的检测，但这不是普通项目必须做满的配置。

第三是流量侧攻击。在不安全的网络上，攻击者可以用中间人方式劫持流量，或者用抓包工具重放请求。如果客户端请求是明文 HTTP，账号密码等于直接裸奔。

第四是交互侧攻击。恶意应用通过导出组件、Intent 劫持、DeepLink 误用等方式，把你的 App 当作跳板。轻则拉起任意页面，重则读取应用内数据。

把这四条路径记在脑子里，后面每一个加固手段对应的是哪条路径，就不会迷茫。

2. 数据存储层加固：敏感数据别裸奔

2.1 明文存储：最常见的裸奔方式

数据存储是 Android 安全里最容易被忽略、出事率却最高的环节。常见场景是：登录 token 存 SharedPreferences，用户手机号存 SQLite，聊天记录直接写文件。开发时觉得方便，上线后才发现问题。

我遇到过一个真实情况。某次协助排查一个用户投诉，说手机换机后用备份恢复，新手机上直接能看到旧 App 里的明文聊天记录。根因就是这个 App 把数据库备份放进了云备份，而数据库本身没有加密。更常见的是，在 root 过的设备上，任何有 root 权限的工具都能直接读取 /data/data/包名/ 下的文件和数据库。

所以第一条规则很简单：明文敏感数据不要落盘。SharedPreferences 里不要放 token、密码、身份证号这类数据；如果一定要存，用加密后的密文。数据库同理，SQLite 默认不加密，需要用加密方案。

下面是典型的错误示范：

val prefs = context.getSharedPreferences("secure_store", Context.MODE_PRIVATE) prefs.edit().putString("user_token", "token_xxx").apply()

这种写法的问题不在于 API 用错，而是 token 直接暴露在明文文件里。任何能读取 App 数据目录的人，都能拿到这个 token，等同于拿到登录态。

2.2 AndroidKeyStore 与对称加密的正确姿势

正确的做法是用加密，但加密方案不是自己写一个 XOR 算法或者固定密钥的 AES，而是把密钥托管给 AndroidKeyStore。

AndroidKeyStore 的核心价值不是帮你做加密运算，而是帮你“保管密钥”。密钥生成之后，私钥或者对称密钥的明文永远不会暴露给应用进程。应用拿到的只是一个 KeyStore 的引用，签名、加密都在系统安全环境里完成。即使攻击者 root 了设备，也很难直接从内存里把密钥抠出来。

用 AES-GCM 举个例子。GCM 模式自带认证标签，能发现密文被篡改，比单纯的 ECB/CBC 安全不少。密钥生成代码如下：

val keyStore = KeyStore.getInstance("AndroidKeyStore") keyStore.load(null) if (!keyStore.containsAlias(ALIAS)) { val keyGenerator = KeyGenerator.getInstance( KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore" ) keyGenerator.init( KeyGenParameterSpec.Builder( ALIAS, KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT ) .setBlockModes(KeyProperties.BLOCK_MODE_GCM) .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE) .build() ) keyGenerator.generateKey() }

加密时用 Cipher 实现：

val cipher = Cipher.getInstance("AES/GCM/NoPadding") cipher.init(Cipher.ENCRYPT_MODE, key) val iv = cipher.iv val encrypted = cipher.doFinal(plainBytes)

这里有一个细节：GCM 模式下的 IV 不需要保密，可以明文和密文拼在一起保存。解密时先取 IV，再还原 Cipher 对象解密。别把 IV 丢了，丢了就解不开了。

如果项目用的是旧设备，AndroidKeyStore 在低版本上可能退化为软件实现，但比完全不用强得多。关键是习惯要先改过来，凡是涉及敏感字段的持久化，都要想一下：如果文件被人拿到，里面的内容能不能被直接读懂？

2.3 数据库加密与备份数据防泄漏

数据库层面，SQLite 默认是明文，解决方案是 SQLCipher 这类加密数据库。SQLCipher 是在 SQLite 之上加了加密层，所有读写都经过 AES 解密加密。和 Room 配合使用时，只需要在数据库工厂里配置密码，业务代码基本不用改。

加密用的口令最好不要硬编码在代码里，可以从 AndroidKeyStore 里生成一个随机密钥，转成 Base64 作为口令传入。这样口令既不是明文，也不会出现在 APK 的字符串资源中。

另外一个很容易被漏掉的点，是 android:allowBackup。很多应用的 AndroidManifest 里这个属性是默认开启的，意味着 adb backup 可以拉走 App 的私有数据。如果 App 里已经有敏感数据，哪怕加密了，也要认真考虑是否允许备份。一般建议敏感应用把 allowBackup 显式设为 false，或者实现自定义 BackupAgent，从备份集合里剔除敏感文件。

再说一个细节：外部存储。把敏感文件放到 getExternalFilesDir 或者公共存储目录，等于把数据放到了不设防的区域。除非明确知道自己在做什么，否则敏感数据一律只放在内部存储，并且使用加密。我的经验是，项目里可以加一条代码评审要求：凡是写入外部存储的文件，必须注明用途，并且不允许包含 token、密钥、用户隐私字段。

3. 网络层防线：从 HTTPS 到 WebView 的坑

3.1 明文流量与网络安全配置

从 Android 9 开始，系统默认禁止明文 HTTP 流量。如果请求目标是 http 地址，会直接抛异常。这个默认行为是好的，但很多项目为了调试方便，会在 Manifest 里把 usesCleartextTraffic 设为 true，然后上线时忘了关。

更稳妥的方式，是用 network_security_config 做精细控制。允许某个开发环境的域名走明文，其余流量强制走 HTTPS。配置如下：

<network-security-config> <base-config cleartextTrafficPermitted="false" /> <domain-config cleartextTrafficPermitted="false"> <domain includeSubdomains="true">api.example.com</domain> </domain-config> </network-security-config>

上面的配置意味着除了 api.example.com 之外，其他请求都不允许明文。开发和测试环境如果确实需要明文，可以单独用 debug 目录下的配置覆盖，不影响 release 包的安全策略。

日常开发时，我建议把“明文流量”作为一个必查项。不是说不允许开发机连本地服务，而是要把 debug 和 release 的配置分开，不要让上线包里残留宽松的网络安全配置。

3.2 证书校验与 Pinning 的取舍

HTTPS 能防普通监听，但防不了中间人攻击。中间人攻击的常见方式是：恶意程序在设备上安装自己的 CA 证书，然后对请求做 TLS 解密。系统默认信任用户安装的 CA，所以如果你的客户端只做了普通的证书链校验，攻击者很容易就能伪装成服务端。

对抗手段是 SSL Pinning，也就是把服务端证书或者公钥的指纹固定到客户端。校验时不仅验证证书链，还验证最终证书是否匹配预设值。这样即使用户安装了恶意 CA，客户端仍然会拒绝连接。

但 Pinning 是一个需要权衡的方案。Pinning 做得太死，证书一换，旧版本 App 立即无法联网。我在实践中更推荐的做法是：使用公钥级别 Pinning，并且和服务端约定好备份指纹。客户端保存两个或以上指纹，当服务端证书轮换时，新指纹能平滑过渡。

这里也要提醒一句：如果你在 debug 包开了抓包代理，而代理工具用的是自签证书，Pinning 会导致抓包失败。这不是 bug，而是预期行为。需要调试时，通过 BuildConfig 字段区分环境，在 debug 模式关闭 Pinning，release 模式强制开启。

3.3 WebView 是重灾区

WebView 的安全问题，要比普通网络请求复杂得多。WebView 本身是一个完整的浏览器内核，加载不可信内容时，各种能力都可能被滥用。

第一是 JavaScript 桥接。addJavascriptInterface 可以让 JS 调用 Java 代码，但如果这个 WebView 加载的是不可信页面，恶意 JS 就可能拿到桥接对象，进而越权调用敏感方法。老版本 Android 上这个风险尤其明显。建议：不要随意打开 JavaScript 桥接，如果必须使用，要限定加载的 URL 域名，并且所有桥接方法都做权限校验。

第二是 file 域访问。setAllowFileAccess 和 setAllowFileAccessFromFileURLs 一旦打开，WebView 里的 JS 就能读取本地文件。正常业务场景很少需要这个能力，默认应该保持关闭。

第三是 URL 校验。WebView 加载外部链接时，如果跳转了intent://或者自定义 scheme，存在打开其他应用的潜在风险。处理方式是做一个统一的 URL 白名单校验，非法的 scheme 一律拦截。之前见过一个案例，页面里一个小广告位被篡改成恶意链接，点击后直接拉起拨号界面，体验和安全都很受影响。

我的习惯是，凡是 WebView 功能都集中封装在一个 WebActivity 里，加载前统一走 URL 检查器，不要每个页面各自处理。

4. 组件与交互层的权限收口

4.1 exported 属性管理：把大门锁好

Android 应用由 Activity、Service、Receiver、Provider 四类组件组成。每个组件都可能被外部应用拉起，前提是 exported 属性为 true，或者定义了 intent-filter。很多项目的组件导出问题不是刻意设计的，而是写着写着就漏了。比如第三方 SDK 回调用的 Activity，或者方便测试而临时暴露的 Service，结果一直没做权限限制。

排查时可以看最终构建产物里的 Manifest。以前我习惯用 aapt：

aapt dump xmltree app-release.apk AndroidManifest.xml

也可以直接用反编译工具查看。重点是找 exported 为 true 的组件，逐一确认：这个组件真的需要被外部应用直接调用吗？如果不需要，就显式设置 exported 为 false。如果需要，要加 signature 级别的权限保护。

举个例子，一个给外部调用的分享 Activity，可以这样声明：

<activity android:name=".activity.ShareActivity" android:exported="true" android:permission="com.example.app.permission.SHARE" />

这样只有持有对应权限签名的应用才能拉起这个 Activity，而不是任何应用都能调。

组件的权限收口是投入产出比很高的安全动作。恶意应用没有你的签名，就无法通过权限检查，这条路就被堵住了。

4.2 Intent 劫持、PendingIntent 与 DeepLink 漏洞

隐式 Intent 是一把双刃剑。你用隐式 Intent 跳转某个页面时，系统会询问所有能处理该 Intent 的应用，其中就可能包括恶意应用。如果这个过程中传递了敏感参数，数据就被劫持了。

处理原则很简单：App 内部跳转，一律使用显式 Intent，直接指定目标组件类名。只有明确需要系统能力（比如拍照、选文件）时才用隐式 Intent，并且使用系统提供的标准动作。

PendingIntent 也有自己的坑。它相当于把一次 Intent 的执行权限延迟交给别人。创建 PendingIntent 时，如果 Intent 没有指定明确的组件，恶意应用可能伪造同样的请求来匹配。更关键的是 mutable 属性：Android 12 以后，PendingIntent 默认 immutable。老项目如果还在用 PendingIntent.FLAG_UPDATE_CURRENT 加隐式 Intent，兼容性之外还要注意安全性。原则是：不需要修改内部 Intent 的地方，都用 FLAG_IMMUTABLE。

DeepLink 的漏洞在于校验不严。如果你的链接使用了自定义 scheme，比如myapp://open?url=xxx，外部应用就能拼接一个恶意 url 参数，诱导 WebView 加载任意页面。处理方式：解析到 URL 之后，必须做 host、path、参数的强校验，并且对最终跳转 URL 做白名单匹配。不要直接在 DeepLink 参数里透传一个 URL 给 WebView。

4.3 Provider 与 ContentResolver 的越权读取

ContentProvider 是另外一个容易被忽视的泄漏口。很多项目里有一个 DataProvider，最初是为了给别的模块读取数据用的，后来模块删了，Provider 却还留在 Manifest 里，而且 exported 为 true。如果没有在 Provider 上做权限保护，任何应用都能通过 ContentResolver 尝试读数据。

需要注意的还有临时授权模式。你通过 FileProvider 给外部应用授权读写文件时，默认会加上 FLAG_GRANT_READ_URI_PERMISSION。这个授权是临时的，用完会自动撤销，但前提是 grantUriPermission 的配置和使用方式正确。不要为了省事把 FileProvider 的 exported 设为 true，正确做法是保持 false，通过 grantsUriPermissions 配合 Intent 临时授权。

一个检查方法：列出项目里所有 Provider，逐个确认对外暴露的数据范围。如果 Provider 只给内部模块用，exported 一定要为 false，权限写清楚。

5. 逆向对抗与代码加固

5.1 混淆这件事，别只把它当交作业

很多项目的混淆配置是从网上抄的模板，只要能编译过、功能不崩，就不管了。但混淆的意义不只是“让代码难看”，它主要有三个作用：符号重命名增加逆向难度、裁剪无用代码降低包体、移除调试信息。对攻击者来说，看到a.a.a()这类方法名，要比看到getUserTokenWithPassword()费劲得多。

R8 和 ProGuard 是主流方案。开了 minifyEnabled 之后，要注意保留规则。凡是反射调用、Gson 序列化模型、注解处理器生成的类，都要写 keep 规则，否则线上会出现运行时崩溃。示例配置：

-keep class com.example.app.model.** { *; } -keepclassmembers class com.example.app.model.** { *; } -keepattributes Signature, *Annotation*

混淆不是加密，不要以为混淆之后代码就安全了。攻击者依然可以用工具反编译、分析调用链、定位核心逻辑。真正的目标是提高逆向成本，让他花一天时间才能看懂的东西，变成花一周。商业加固可以在混淆基础上再做一层防脱壳和保护，但那是另一个话题。

5.2 签名校验、防调试与完整性自检

二次打包是 Android 应用常见的攻击方式。攻击者把 APK 解包、注入广告代码、重新签名，再放到应用市场诱导下载。签名校验的作用，是在运行时验证当前 APK 的签名是否正确，检测到签名不一致就直接退出。

实现思路是：在 Application 初始化时读取 APK 的签名信息，和服务端下发的或者本地保存的合法签名比对。需要注意两点。第一，本地保存的签名指纹会被攻击者找到，所以不能只依赖本地判断，重要操作建议把签名信息传给服务端二次校验。第二，校验代码本身要藏好，不要写成一个方法签名一眼就能看出来的独立类。

防调试检测是另一个常见手段。Debug.isDebuggerConnected()能检查调试器是否连接，Linux 下的/proc/self/status里的 TracerPid 字段也能反映进程是否被跟踪。这类检测只能增加动态分析的难度，无法根除。更实际的目标是：让攻击者在调试你的应用时多花时间，而不是轻易在模拟器里跑起来。

root 检测也类似。很多团队喜欢做 root 检测后直接拒绝运行，但 root 用户可以用 Magisk 隐藏 root，这个检测形同虚设。我的看法是，root 检测可以作为风控的一环，把检测结果上报服务端，而不是当成唯一的防护手段。

5.3 加固工具怎么选

市面上有成熟的商业加固方案，也有开源方案，选择时要考虑三个维度。

兼容性排第一。加固后的 APK 要在不同 Android 版本上稳定运行，如果加固引入的 crash 比攻击者造成的损失还大，那就不值得。性能开销排第二。启动时解密、运行时校验都会增加耗时，敏感逻辑多的应用尤其要关注启动耗时变化。更新频率排第三。加固方案如果停止维护，新系统一出来就无法适配，风险很大。

我的建议是：核心业务先做混淆和签名校验，确认稳定后再评估是否上商业加固。不要为了追求“绝对安全”把启动时间拖慢，用户体验也是安全的一部分。

6. 落地自查清单与常见问题速查

6.1 上线前的一套安全自检动作

安全改造最怕的是没有抓手。我把每次发版前的安全自检做成了固定动作，按顺序过一遍，大概半小时就能完成。

第一步，检查组件导出。把最终 release 包的 Manifest 导出来，逐项看 exported。凡是没必要暴露的组件，全部置为 false。

第二步，抓包看流量。用代理工具或者开发环境配置，看一下 App 启动、登录、数据刷新时的全部请求，确认没有明文账号密码、token、手机号。所有请求都应该走 HTTPS，并且带有效证书校验。

第三步，检查本地数据。在 root 过的设备或者模拟器上安装 App，跑一遍核心流程，然后进入 /data/data/包名/ 目录，翻一遍 SharedPreferences、数据库、缓存文件。敏感字段应该是不可读的密文。

第四步，核对混淆和加固策略。确认 minifyEnabled 和 shrinkResources 已开启，混淆映射文件有存档，线上 crash 能通过 mapping 还原。如果用了第三方加固，确认当前版本在新系统上有灰度结果。

第五步，审查第三方 SDK 权限。打开最终包，检查所有权限声明，列出第三方 SDK 申请的权限。不合理的权限要和 SDK 接入负责人确认，不要在代码评审时放过。

6.2 常见问题排查表

6.3 第三方 SDK 安全：容易被忽略的暗雷

很多团队的安全意识只停留在自己写的代码上，对第三方 SDK 却格外宽松。实际上 SDK 带来的风险可能更大：你不知道它内部网络请求是否走明文，不知道它把哪些数据写进了本地文件，也不知道它动态加载了什么代码。

我对第三 SDK 的底线要求是权限最小化。接入一个推送 SDK，不应该顺便申请通讯录权限；接入一个统计 SDK，不应该把设备剪切板内容采集走。每次发版前，可以用依赖清单结合 Manifest 检查工具，看一眼最终包里的权限声明有没有异常膨胀。

另一个建议是，敏感逻辑尽量放在自己的进程和应用内，不要通过 SDK 开放的接口把核心数据传出去。如果一个 SDK 声称提供“安全风控”，但是需要你上传完整通讯录，这个“安全”就要打个问号。

我在实际开发中的体会是，Android 安全不是一个独立阶段，而是一组贯穿需求、开发、测试、发布全流程的习惯。给新功能写代码时，多问一句“如果这个数据被人拿到了会怎样”；合代码前，多想一句“这个组件是否真的需要被外部拉起”。把这些变成肌肉记忆之后，安全就不会停留在概念层面。

这里再分享一个实操技巧：把前面 6.1 的检查动作固化成一个 Markdown 模板，每轮发版前拉出来逐条打勾。刚开始做的时候可能会发现一堆历史遗留问题，不要慌，按优先级逐个修。我的经验是，存储加密和组件导出是性价比最高的两个起点，修完之后，绝大多数容易被利用的低级漏洞都会被堵住。