跨平台 APP 資安完整指南：OWASP Mobile Top 10、API 防護與企業資料加密實戰（2026）
2025 年 OWASP 公布的 Mobile Top 10 比 2016 版多了一倍的攻擊面，其中與「不安全的通訊」「不充分的供應鏈安全」「不安全的身分驗證 / 授權」相關的攻擊事件，在台灣金融、電商、醫療三大產業都已留下案例。對企業來說，APP 一旦上架，等同把品牌的入口暴露在所有惡意分析師面前；而跨平台框架（React Native、Flutter）為了開發效率採用 JavaScript / Dart 打包，反而讓逆向、反組譯與動態 hook 變得更容易。
這篇文章不是學術整理，而是山葵組在實際幫企業做 React Native APP 上架前後拉資安的 SOP。我們會用 OWASP Mobile Top 10 為骨架，逐項對應到跨平台 APP 的常見坑、實作上的選擇，以及最後的上架前檢查清單，幫你把資安從口號變成可驗證的工程動作。
一、為什麼跨平台 APP 的資安比想像中脆弱
很多企業誤以為「我們有 SSL、有 JWT，APP 就安全了」，這個假設在 2026 年已經完全站不住腳。跨平台 APP 的資安弱點主要來自三個結構性原因：
1. JavaScript / Dart bundle 容易被逆向：React Native 預設會把整包 JS bundle 打進 APK / IPA，攻擊者只要解壓 APK、用 react-native-decompiler 或 hermes-decompiler 就能拿到接近原始碼的內容；Flutter 雖然編譯成原生 binary，但 reFlutter、Doldrums 之類的工具同樣能還原大部分商業邏輯。
2. 第三方套件供應鏈過長：一個典型的 React Native APP 會引用 200~600 個 npm 套件，每多一個套件就多一個被植入惡意程式碼或 token 竊取的風險。2024 年 lottie-player CDN 事件就是典型例子。
3. 客戶端與伺服器邊界模糊：很多團隊把驗證邏輯寫在 APP 端，例如「如果 user.role === 'admin' 才顯示後台按鈕」，這種寫法在 Web 時代就被詬病，搬到 APP 反而更危險，因為攻擊者可以離線改 bundle 後重新打包。
二、OWASP Mobile Top 10（2024 版）對應的跨平台攻擊面
OWASP 在 2024 年更新的 Mobile Top 10 把不少老項目重組，下面整理跨平台 APP 最容易踩中的幾項：
M1：不正確的憑證使用：把 API Key、Firebase 設定、JWT Secret 直接 hardcode 在 JS bundle 裡，幾乎是跨平台 APP 最常見的問題。建議所有 secret 透過 react-native-config + 加密 build pipeline 管理，並且把高權限 key 留在伺服器端。
M2：不充分的供應鏈安全：使用 npm audit、Snyk 或 GitHub Dependabot 持續掃描；高風險套件改用 patch-package 鎖版本；CI/CD 階段加上 SBOM（Software Bill of Materials）紀錄。
M3：不安全的身分驗證 / 授權：永遠不要相信來自 client 的 user.role 或 user.id；所有授權檢查在 API server 重做一次。Token 使用 short-lived access token + refresh token 機制，access token 不超過 15 分鐘。
M4：不充分的輸入 / 輸出驗證：API 端必須對所有輸入做 schema 驗證（Zod、Joi、class-validator），輸出端避免直接 dump database row。
M5：不安全的通訊：除了基本的 HTTPS，企業級 APP 要做 TLS Pinning，避免使用者裝 Charles 或 Frida 在中間人解密流量。
M6：不充分的隱私控制：iOS App Tracking Transparency 與 Privacy Manifest（2024 起強制）必須完整填寫，否則上架審核會被退件。
M7：不充分的二進位保護：Android 採用 R8 + ProGuard 規則 + 字串加密；iOS 用 Bitcode（已淘汰）改用 LLVM 級別的 obfuscation 工具。
M8：安全性配置錯誤：例如 debug build 流出、開啟 allowBackup、AndroidManifest 中 exported activity 設定錯誤。
M9：不安全的資料儲存：絕對不要用 AsyncStorage / SharedPreferences 儲存 token 或 PII，改用 react-native-keychain（iOS Keychain / Android Keystore）。
M10：不充分的密碼學：避免自己實作加密；統一用 libsodium 或 platform 內建的 CryptoKit / Tink。
三、API 防護：跨平台 APP 真正的資安戰場
跨平台 APP 的 90% 攻擊都會回到 API 層，因為前端不論怎麼包都會被解開，伺服器端才是最後的守門員。山葵組在企業專案上會做以下五件事：
1. TLS Pinning：使用 react-native-ssl-pinning 或原生 NSURLSession + URLSessionDelegate 做憑證綁定，憑證輪替建議 90 天並支援雙憑證 fallback。
2. Request Signing：每個 API request 用 HMAC-SHA256 簽章 timestamp + body，伺服器端驗證 5 分鐘有效時窗，可以防止 replay attack。
3. Rate Limiting + Anomaly Detection：API Gateway 層（Kong、AWS API Gateway、Cloudflare Workers）加上 IP-based 與 user-based 雙層 rate limit，並把異常流量送到 SIEM。
4. 最小權限 JWT：JWT 只放 user id 與 role，不放 PII；access token 15 分鐘、refresh token 7 天；refresh token 使用 rotation 並紀錄到 server-side blacklist。
5. Server-side Receipt 驗證：In-App Purchase 收據 100% 在伺服器端用 App Store Server API / Google Play Developer API 重新驗證，不依賴 client 回傳結果。
四、本機資料加密：別讓使用者的手機變成資料庫
使用者的手機 = 攻擊者的研究實驗室。被 root 或 jailbreak 的裝置上，所有未加密的本機檔案都可被讀取。建議分層處理：
機敏資料（token、生物辨識金鑰、PII）：使用 react-native-keychain 或 expo-secure-store。底層自動使用 iOS Keychain（Secure Enclave）與 Android Keystore（StrongBox 若硬體支援）。
應用快取（API response、圖片）：使用 react-native-mmkv 並開啟 encryptionKey，比 AsyncStorage 快 30 倍且原生支援加密。
大型檔案（PDF、影片快取）：放在 NSFileProtectionComplete（iOS）或 EncryptedFile（Android Jetpack Security）目錄。
Root / Jailbreak 偵測：用 jail-monkey 或 freeRASP 偵測，偵測到後不直接 crash，而是降級顯示「環境不安全，請改用其他裝置」並阻擋敏感功能。
五、認證與授權設計：從密碼到生物辨識
跨平台 APP 的認證設計建議採用三層：
第一層：登入：優先使用 OAuth 2.0 + PKCE（Google / Apple Sign-In / LINE Login），降低自管密碼風險。如必須自管，密碼用 Argon2id 雜湊，並要求至少 12 字元 + passphrase。
第二層：MFA：對於企業內部 APP 或金融 APP，登入後必須 OTP 或 Push-based 二次驗證。建議使用 TOTP（Google Authenticator / Authy）而非 SMS，因為 SIM swap 攻擊在台灣已多次出現。
第三層：本機快速解鎖：成功登入後 token 存入 Keychain / Keystore，下次開啟 APP 用 react-native-biometrics 做 FaceID / TouchID 解鎖即可，不必每次重新登入。Token 過期或裝置被 root，自動降級回 MFA。
六、第三方 SDK 與供應鏈風險管理
Sentry、Firebase、Mixpanel、AppsFlyer、Branch、推播服務、客服 SDK……一個企業 APP 平均整合 8~15 個第三方 SDK。每一個 SDK 都是潛在的資料外洩管道。山葵組的處理原則：
盤點與分級：每個 SDK 列出資料蒐集範圍（device id、user id、event log、location）、傳輸目的地（國家 / 公司）與隱私政策版本。
鎖版本：package.json 用 exact version，不用 caret；CI 階段 lock-file 通過簽章驗證。
SBOM 與審計：每次 release 產生 SBOM（CycloneDX 格式）並保留 6 個月，方便事後溯源。
替換邏輯：高風險 SDK（例如疑似中資背景的廣告 SDK）建議在 R&D 路線圖中安排替代方案，至少有 6 個月的退出期。
七、滲透測試與持續性資安
資安不是「上架前測一次就好」，而是要納入 CI/CD 與例行性檢測：
SAST / SCA：CI pipeline 加入 SonarQube + Snyk，PR 階段就擋下高風險變更。
DAST：每季用 MobSF 或 Quark Engine 對 build artifact 做動態掃描。
滲透測試：年度委託第三方資安顧問（如 DEVCORE、奧義智慧、戴夫寇爾）做白箱滲透，台灣常見報價約 25 萬~80 萬，視 APP 規模而定。
Bug Bounty：上架後可考慮在 HackerOne 或 BugCrowd 開設私有計劃，1 萬 ~ 10 萬美元 / 年的預算就能換到全球白帽的持續監測。
八、跨平台 APP 上架前資安檢查清單
下列項目建議在每次大版本上架前逐項勾選：
□ 所有 API key / secret 已從 JS bundle 移除，改用伺服器端代簽
□ Release build 已關閉 console.log，並啟用 Hermes / R8 / ProGuard
□ AndroidManifest.xml：android:allowBackup="false"、android:debuggable="false"、所有 exported activity 顯式宣告
□ Info.plist：完整填寫所有 NSXxxUsageDescription 與 PrivacyInfo.xcprivacy
□ 所有 token 與 PII 改用 Keychain / Keystore，不出現在 AsyncStorage / SharedPreferences
□ TLS Pinning 已啟用並通過 Charles / Burp 驗證無法解密
□ JWT access token ≤ 15 分鐘，refresh token rotation 已啟用
□ Root / Jailbreak 偵測已啟用，敏感功能在不安全環境下被阻擋
□ 第三方 SDK 已完成資料蒐集盤點，SBOM 已產生
□ MobSF 動態掃描通過，無 Critical / High 風險
□ App Store Privacy Manifest 與 Google Play Data Safety 已填寫並與實際相符
□ 測試帳號 / 測試金流（綠界沙盒、TapPay 測試卡）已從 release build 移除
結語：把資安做成可驗證的工程，而不是口號
跨平台 APP 的資安沒有銀彈，所有防線都會被技術夠強的攻擊者突破，差別只在於「需要多久」與「攻擊成本」。把資安從感覺變成可驗證的工程動作，就是把每一條防線（程式碼混淆、TLS Pinning、Keystore、Server-side Validation、SBOM、Pen Test）都寫進 CI/CD 與發版流程，讓每一次更新都通過同樣的檢查。
山葵組在每個企業級跨平台 APP 專案，都會把上面這份清單嵌入合約 SLA 與交付驗收，並提供 12 個月的資安維護方案。如果你正在評估一個 APP 專案，或是手上 APP 已經上架但從來沒有做過完整資安檢測，歡迎與我們聊聊；資安越早處理，成本越低。