App 加固要保護什麼？
先列資產，再選工具
行動應用的威脅模型應區分公開內容、會員資料、付費權益與企業專有演算法。反逆向工程能增加拆解與修改成本，但裝置不完全由企業掌握，無法保證程式永遠不可分析。因此防護設計應假設部分客戶端邏輯可能被看見，再確認哪些決策必須留在後端。
例如優惠資格、付款金額與跨公司資料查詢，不應僅由 App 傳回一個成功旗標決定。後端要重新計算或核對必要條件。本機則只保留完成操作所需資料，登出、帳號停用及裝置遺失時都要有對應的憑證與快取清除策略。
代碼混淆與秘密管理
讓攻擊成本提高，也讓憑證可撤銷
代碼混淆可以改變符號名稱與程式結構，降低直接閱讀的便利性；正式版也應移除多餘除錯資訊與敏感日誌。混淆規則必須經回歸測試，尤其是反射、序列化及第三方 SDK，否則可能在某些裝置上才出現難以重現的錯誤。
真正需要保密的服務端密鑰不應打包到 App。即使字串被加密，解密所需的程式仍可能被分析。可由後端代為呼叫服務，或使用權限受限、有效期短的憑證。平台必須暴露的公開識別值，也應配合服務端限制、用量監控與撤銷機制。
憑證綁定如何落地？
HTTPS 是基礎，Pinning 是有條件的加強
一般 TLS 驗證會檢查憑證鏈與主機名稱；憑證或公鑰綁定再限制可接受的伺服器身分。這可降低部分攔截情境的風險，但不適合在沒有憑證治理能力時直接套用。若憑證更新後舊版 App 全部無法連線，安全措施本身也會形成營運事件。
設計時需確認綁定憑證還是公鑰、備用金鑰如何預先配置，以及舊版 App 的支援期限。驗收要包含正常輪替與緊急換鑰，不能只測試當下的一張憑證。也不應提供可被任意開啟的「忽略憑證錯誤」開關作為便利維運手段。
完整性與風險分級
辨識異常後，要有合適的處理方式
可依平台能力評估 App 完整性訊號、除錯偵測及執行環境風險，將結果傳回後端做風險判斷。單一訊號可能存在誤判，也可能被繞過，因此不宜只靠一個布林值決定所有使用者是否可用。高風險交易與一般內容瀏覽可採不同控制強度。
對付款、敏感資料匯出或管理操作，可要求重新驗證、限制頻率或人工確認；對一般查詢則可降低回傳資訊。錯誤訊息要讓合法使用者知道可行的下一步，並提供支援識別碼，而不是暴露偵測細節或把所有裝置問題都描述成遭到入侵。
如何驗收行動應用防護？
測試發布成品與真實升級路徑
測試對象應是實際簽章、混淆後的發布套件，涵蓋不同作業系統版本、網路環境與更新路徑。檢查本機儲存、螢幕快照、日誌與網路請求是否包含不必要的敏感資料，再確認錯誤回報不會把完整權杖上傳到監控平台。
依 OWASP MASVS 與 MASTG 選擇適用的控制與測試，可讓雙方對驗收範圍有共同語言。報告要列明版本、環境、發現、修正與複測結果；「通過弱掃」不應被解讀為所有逆向風險已消失，也不能取代 API 的物件層級權限測試。
成本與維運如何評估？
把上架後的更新納入交付
比較加固工具時，應同時估算授權費、建置時間、效能影響與故障排查成本。對需要高頻發布的 App，還要確認簽章、混淆規則及測試能否穩定自動化。供應商工具停用或不支援新版作業系統時，也應保有可替換的方案。
專案可先從秘密移出客戶端、TLS 設定與本機敏感資料整理開始，再依交易價值加上完整性及反逆向控制。交付時確認憑證輪替窗口、舊版停用政策與緊急發布責任，讓安全能力能隨 App 生命週期持續運作。
常見問題
代碼混淆可以完全防止抄襲嗎？
不能保證。它是增加分析成本的手段；核心秘密、授權與交易判斷仍應放在受控後端，並搭配權限及監控。
所有 App 都需要憑證綁定嗎？
應依資料敏感度與維運能力評估。若採用，必須設計備用金鑰、輪替測試與舊版相容策略，不能只打開功能就結案。
加固會影響效能或上架嗎？
可能影響建置、啟動與相容性。應在正式套件與支援裝置上量測，並確認所用機制符合平台當時的上架規範。