OWASP Mobile & IoT Top 10 完整指南：2024 行動與物聯網安全漏洞解析【2026 更新】

TL;DR

• OWASP Mobile Top 10 2024 版是自 2016 年以來的首次重大更新
• 新增「憑證使用不當」和「供應鏈安全」兩大新風險類別
• OWASP IoT Top 10 針對物聯網設備的十大安全風險
• MASVS 是 Mobile App 的安全驗證標準，分 L1/L2/R 三個等級
• MASTG 是 Mobile App 安全測試的實作指南
• App 和 IoT 安全需要從設計階段就開始考量

版本說明：本文涵蓋 OWASP Mobile Top 10 2024 版（2024 年正式發布）以及 IoT Top 10。2024 版相較 2016 版有重大變更，新增了供應鏈安全和憑證管理等現代化議題。

---

Part 1：OWASP Mobile Top 10

什麼是 OWASP Mobile Top 10？

OWASP Mobile Top 10 是針對行動應用程式的十大安全風險清單。涵蓋 iOS 和 Android 平台常見的漏洞類型。

行動 App 的安全挑戰和網頁應用不同：

• 程式碼在使用者裝置上執行
• 可能被逆向工程分析
• 需要處理裝置特有的安全機制
• 網路環境不可控（公共 WiFi）

2024 版是自 2016 年以來的首次重大更新，反映了過去 8 年行動安全領域的演變：

2024 版重大變更	說明
新增 M1：憑證使用不當	強調身份驗證方法和使用者身份保護
新增 M2：供應鏈安全	涵蓋從開發到發布的整個生命週期風險
隱私控制獨立成項	反映 GDPR、CCPA 等法規要求
二進位保護更受重視	防止逆向工程和程式碼竄改

想了解 OWASP 組織和網頁安全標準，可以參考 OWASP 完整指南。

插圖：手機畫面顯示一個 App 介面，周圍環繞十個圖示代表不同的安...

場景描述： 手機畫面顯示一個 App 介面，周圍環繞十個圖示代表不同的安全風險類型，包括鎖頭、資料庫、網路、加密等符號。背景為淺灰色。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: owasp-mobile-top-10-overview

---

Mobile Top 10 漏洞解析（2024 版）

以下是 OWASP Mobile Top 10 2024 版的完整漏洞清單，與 2016 版相比有重大變更。

---

M1：Improper Credential Usage（憑證使用不當）🆕

說明： 應用程式在處理使用者憑證時存在缺陷，包括不安全的儲存、傳輸或驗證。

2024 版新增此項：反映了對身份驗證方法和使用者身份保護的更高重視。

常見問題：

• 在程式碼中寫死（hardcode）API 金鑰或密碼
• 在不安全的位置儲存憑證
• 憑證在傳輸過程中未加密
• 缺乏適當的憑證輪換機制
• 未正確實作生物辨識驗證

攻擊情境：

開發者將 API 金鑰寫死在 App 中
攻擊者反組譯 APK/IPA 檔案
取得金鑰後可冒用身份存取後端服務

防護措施：

1. 使用 Keychain (iOS) / Keystore (Android) 安全儲存憑證
2. 實作 OAuth 2.0 + PKCE 進行身份驗證
3. 憑證應由伺服器端動態提供，而非寫死
4. 實作憑證過期和刷新機制
5. 使用硬體安全模組（如 Secure Enclave）保護敏感資料

---

M2：Inadequate Supply Chain Security（供應鏈安全不足）🆕

說明： App 使用的第三方程式庫、SDK 或開發工具存在安全風險。

2024 版新增此項：反映了對整個開發生命週期安全的重視。

風險來源：

• 包含已知漏洞的第三方 SDK
• 遭惡意程式碼注入的 npm/Maven/CocoaPods 套件
• 不安全的 CI/CD 管道
• 未驗證的程式碼簽章
• 供應商遭入侵後的間接影響

攻擊情境：

App 使用了一個熱門的圖片處理 SDK
該 SDK 被駭客入侵，植入後門
所有使用該 SDK 的 App 都受影響

防護措施：

1. 維護完整的 SBOM（Software Bill of Materials）
2. 定期掃描依賴套件的已知漏洞（Dependabot、Snyk）
3. 驗證第三方程式庫的完整性和來源
4. 實作安全的 CI/CD 流程
5. 監控供應商的安全公告

---

M3：Insecure Authentication/Authorization（認證/授權不安全）

說明： App 的身份驗證或權限控制機制存在漏洞。

常見問題：

• 只在客戶端驗證身份
• 使用弱密碼政策
• 缺乏多因素認證
• Session Token 管理不當
• 授權檢查可被繞過

防護措施：

1. 所有認證邏輯都在伺服器端執行
2. 實作強密碼政策和帳戶鎖定
3. 支援多因素認證（MFA）
4. 使用安全的 Session 管理機制
5. 實作完整的授權矩陣

---

M4：Insufficient Input/Output Validation（輸入/輸出驗證不足）

說明： App 未正確驗證使用者輸入或系統輸出，可能導致注入攻擊或資料洩露。

常見問題：

• SQL Injection
• 跨站腳本攻擊（XSS）
• Path Traversal
• XML/JSON 注入
• 格式字串漏洞

防護措施：

1. 對所有使用者輸入進行驗證和清理
2. 使用參數化查詢防止注入
3. 輸出資料時進行適當編碼
4. 實作白名單驗證而非黑名單

---

M5：Insecure Communication（不安全的通訊）

說明： App 與伺服器之間的通訊未受到適當保護。

常見問題：

• 使用 HTTP 而非 HTTPS
• 接受無效或自簽憑證
• 未實作 Certificate Pinning
• 使用過時的 TLS 版本
• 敏感資料在傳輸中未加密

防護措施：

1. 強制使用 HTTPS（TLS 1.3）
2. 實作 Certificate Pinning
3. 驗證伺服器憑證的有效性
4. 使用 App Transport Security (iOS) / Network Security Config (Android)

---

M6：Inadequate Privacy Controls（隱私控制不足）

說明： App 收集、處理或儲存個人資料的方式不符合隱私規範。

常見問題：

• 收集過多不必要的個人資料
• 未告知使用者資料收集行為
• 未提供資料刪除選項
• 與第三方共享資料未經同意
• 違反 GDPR、CCPA 等法規

防護措施：

1. 實作資料最小化原則
2. 提供清楚的隱私政策說明
3. 支援使用者資料匯出和刪除
4. 取得明確的使用者同意
5. 確保符合當地隱私法規

---

M7：Insufficient Binary Protections（二進位保護不足）

說明： App 的二進位檔案缺乏防護，容易被逆向工程或竄改。

常見問題：

• 缺乏程式碼混淆
• 未偵測 Root/Jailbreak
• 缺乏反調試機制
• 未實作完整性檢查
• 敏感字串未加密

防護措施：

1. 使用 ProGuard/R8 (Android) 或類似工具混淆程式碼
2. 偵測 Root/Jailbreak 環境
3. 實作反調試和反模擬器偵測
4. 使用程式碼簽章和完整性驗證

---

M8：Security Misconfiguration（安全設定錯誤）

說明： App 或後端服務的安全設定不當。

常見問題：

• Debug 模式在正式版開啟
• 預設帳密未更改
• 錯誤訊息暴露敏感資訊
• 不必要的服務或端口開啟
• 過於寬鬆的權限設定

防護措施：

1. 建立安全的預設設定
2. 自動化安全設定檢查
3. 移除不必要的功能和服務
4. 定期審查安全設定

---

M9：Insecure Data Storage（不安全的資料儲存）

說明： 敏感資料以不安全的方式儲存在裝置上。

風險位置：

• SharedPreferences / NSUserDefaults（明文儲存）
• SQLite 資料庫（未加密）
• 本地檔案系統
• 系統日誌（Log）
• 剪貼簿
• 備份檔案

攻擊方式：

• 惡意 App 讀取共享儲存空間
• 裝置遺失或被竊
• 透過備份檔案取得資料
• Root/Jailbreak 後存取 App 沙箱

防護措施：

// iOS - 使用 Keychain 儲存敏感資料
let query: [String: Any] = [
    kSecClass as String: kSecClassGenericPassword,
    kSecAttrAccount as String: "userToken",
    kSecValueData as String: tokenData,
    kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlocked
]
SecItemAdd(query as CFDictionary, nil)

// Android - 使用 EncryptedSharedPreferences
val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val sharedPreferences = EncryptedSharedPreferences.create(
    context,
    "secret_prefs",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

M3：Insecure Communication（不安全的通訊）

說明： App 與伺服器之間的通訊沒有適當保護。

常見問題：

• 使用 HTTP 而非 HTTPS
• 接受無效或自簽憑證
• 沒有實作 Certificate Pinning
• 敏感資料在 URL 中傳遞

攻擊情境：

使用者在咖啡店連公共 WiFi
攻擊者執行中間人攻擊 (MITM)
攔截 App 的網路流量
竊取登入憑證或 Session Token

防護措施：

1. 強制使用 HTTPS
2. 實作 Certificate Pinning
3. 驗證伺服器憑證
4. 敏感資料不放 URL

// iOS - Certificate Pinning 範例
let serverTrustPolicy = ServerTrustPolicy.pinCertificates(
    certificates: ServerTrustPolicy.certificates(),
    validateCertificateChain: true,
    validateHost: true
)

M4：Insecure Authentication（不安全的認證）

說明： App 的使用者認證機制有漏洞。

常見問題：

• 允許離線認證被繞過
• 弱密碼政策
• 沒有實作帳號鎖定
• Session 管理不當
• 生物辨識實作有缺陷

防護措施：

1. 認證邏輯放在伺服器端
2. 使用標準認證協定（OAuth 2.0）
3. 實作多因素認證
4. Session Token 安全儲存和傳輸

M5：Insufficient Cryptography（加密不足）

說明： 使用了不安全的加密方式，或加密實作有缺陷。

常見問題：

• 使用已知不安全的演算法（MD5、SHA1、DES）
• 金鑰寫死在程式碼中
• 自行實作加密演算法
• 金鑰管理不當

錯誤示範：

// 錯誤：金鑰寫死在程式碼
private static final String SECRET_KEY = "MySecretKey123";

// 錯誤：使用不安全的演算法
MessageDigest md = MessageDigest.getInstance("MD5");

正確做法：

// 使用 Android Keystore 生成和儲存金鑰
KeyGenerator keyGenerator = KeyGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore");
keyGenerator.init(
    new KeyGenParameterSpec.Builder("MyKey",
        KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT)
        .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
        .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
        .build());
SecretKey key = keyGenerator.generateKey();

M6：Insecure Authorization（不安全的授權）

說明： App 的權限檢查有漏洞，使用者可以存取不該存取的功能或資料。

常見問題：

• 只在客戶端檢查權限
• 可以透過修改請求存取他人資料
• 隱藏功能只是 UI 隱藏，沒有後端驗證

這和 OWASP Top 10 的 A01 Broken Access Control 類似。

防護措施：

1. 所有權限檢查在伺服器端執行
2. 驗證請求者身份和資源擁有權
3. 不要信任客戶端傳來的角色資訊

M7：Client Code Quality（客戶端程式碼品質）

說明： 程式碼品質問題導致安全漏洞。

常見問題：

• 緩衝區溢位
• 格式化字串漏洞
• 記憶體洩漏
• 未處理的例外
• 競爭條件（Race Condition）

防護措施：

1. 使用記憶體安全的語言（Swift、Kotlin）
2. 靜態程式碼分析
3. 程式碼審查
4. 模糊測試（Fuzzing）

M8：Code Tampering（程式碼竄改）

說明： 攻擊者修改 App 的程式碼或執行環境。

攻擊方式：

• 修改 APK/IPA 重新打包
• Hook 函數改變行為
• 修改執行時期記憶體
• 在越獄/Root 裝置上執行

防護措施：

1. 程式碼混淆
2. 完整性檢查
3. Root/Jailbreak 偵測
4. 反調試機制
5. Runtime 保護

// Android - 簽章驗證範例
public boolean verifySignature(Context context) {
    try {
        PackageInfo packageInfo = context.getPackageManager()
            .getPackageInfo(context.getPackageName(),
                PackageManager.GET_SIGNATURES);
        for (Signature signature : packageInfo.signatures) {
            String currentSignature = signature.toCharsString();
            if (!currentSignature.equals(EXPECTED_SIGNATURE)) {
                return false;
            }
        }
        return true;
    } catch (Exception e) {
        return false;
    }
}

M9：Reverse Engineering（逆向工程）

說明： 攻擊者分析 App 的程式碼，找出漏洞或竊取商業邏輯。

攻擊目的：

• 找出 API 端點和參數
• 提取寫死的金鑰或憑證
• 理解商業邏輯以便繞過
• 製作盜版或惡意修改版

常用工具：

• Android：jadx、apktool、Frida
• iOS：class-dump、Hopper、IDA Pro

防護措施：

1. 程式碼混淆（ProGuard、R8、SwiftShield）
2. 字串加密
3. 控制流程混淆
4. 原生程式碼（NDK/C++）
5. 商業保護方案

M10：Extraneous Functionality（多餘功能）

說明： App 中存在開發階段的後門或測試功能，被攻擊者利用。

常見問題：

• 隱藏的管理員入口
• 測試用的繞過機制
• 開發用的日誌輸出
• 未移除的測試帳號
• 註解中的敏感資訊

防護措施：

1. 建立正式發布檢查清單
2. 自動化掃描隱藏功能
3. 程式碼審查
4. 分離開發/正式環境設定

---

OWASP MASVS 與 MASTG

除了 Mobile Top 10，OWASP 還提供了更完整的 Mobile 安全框架。

MASVS（Mobile Application Security Verification Standard）

MASVS 是行動 App 安全驗證標準。定義了 App 應該達到的安全要求。

三個驗證等級：

等級	名稱	適用場景
L1	Standard Security	一般 App
L2	Defense-in-Depth	處理敏感資料的 App
R	Resiliency	需要防止逆向工程的 App

MASVS 控制項分類：

• MASVS-STORAGE：資料儲存
• MASVS-CRYPTO：加密
• MASVS-AUTH：認證授權
• MASVS-NETWORK：網路通訊
• MASVS-PLATFORM：平台互動
• MASVS-CODE：程式碼品質
• MASVS-RESILIENCE：防逆向

MASTG（Mobile Application Security Testing Guide）

MASTG 是 MASVS 的實作指南。詳細說明如何測試每一項控制項。

內容包含：

• iOS/Android 平台安全機制說明
• 每項控制項的測試方法
• 測試工具使用教學
• 測試案例範例

這兩份文件是做 Mobile App 安全評估的必備參考。

想知道你的 App 符合 MASVS 哪個等級？

---

Mobile App 安全測試工具

MobSF（Mobile Security Framework）

開源的自動化 Mobile App 安全測試框架。

功能：

• 靜態分析（不需執行 App）
• 動態分析（執行時期測試）
• 支援 Android APK、iOS IPA、原始碼
• 自動產生報告

使用方式：

# Docker 安裝
docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf

# 開啟瀏覽器
# http://localhost:8000
# 上傳 APK/IPA 即可分析

QARK（Quick Android Review Kit）

LinkedIn 開源的 Android App 靜態分析工具。

特點：

• 專注於找出安全漏洞
• 可分析 APK 或原始碼
• 產生詳細的漏洞報告

# 安裝
pip install qark

# 分析 APK
qark --apk path/to/app.apk

# 分析原始碼
qark --java path/to/source/

Frida

強大的動態分析框架。可以即時 Hook 和修改 App 行為。

用途：

• 繞過 SSL Pinning
• 分析加密邏輯
• 修改函數回傳值
• 追蹤函數呼叫

// Frida Script - 繞過 Root 偵測
Java.perform(function() {
    var RootCheck = Java.use("com.app.security.RootCheck");
    RootCheck.isRooted.implementation = function() {
        console.log("Root check bypassed");
        return false;
    };
});

搭配 OWASP ZAP 可以對 App 的 API 進行更完整的測試。

插圖：電腦螢幕顯示 MobSF 介面，左側為 Android Ap...

場景描述： 電腦螢幕顯示 MobSF 介面，左側為 Android App 分析結果摘要，包含安全分數、發現的漏洞數量。右側顯示詳細的漏洞清單和嚴重程度標示。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: mobsf-mobile-security-testing

---

Part 2：OWASP IoT Top 10

什麼是 OWASP IoT Top 10？

OWASP IoT Top 10 是針對物聯網設備的十大安全風險清單。

IoT 設備的安全挑戰：

• 運算資源有限，難以實作完整安全機制
• 更新機制不完善
• 預設配置不安全
• 供應鏈複雜
• 生命週期長（可能運作十年以上）

2018 版是目前最新版本。涵蓋從硬體到雲端的完整 IoT 生態系。

---

IoT Top 10 漏洞解析

I1：Weak, Guessable, or Hardcoded Passwords

中文：弱密碼、可猜測密碼、寫死密碼

問題：

• 使用 admin/admin、root/root 等預設密碼
• 密碼寫死在韌體中
• 沒有強制使用者修改預設密碼
• 弱密碼政策

真實案例： 2016 年 Mirai 殭屍網路攻擊。利用 IoT 設備的預設密碼，感染數十萬台設備，發動史上最大 DDoS 攻擊。

防護措施：

1. 強制首次使用時修改密碼
2. 每台設備使用唯一預設密碼
3. 禁止弱密碼
4. 支援多因素認證

I2：Insecure Network Services

中文：不安全的網路服務

問題：

• 開啟不必要的網路服務
• 服務有已知漏洞未修補
• 沒有認證就能存取
• 暴露管理介面

常見問題服務：

• Telnet（明文傳輸）
• 未設密碼的 SSH
• 公開的管理網頁
• UPnP（自動開啟 Port）

防護措施：

1. 關閉非必要服務
2. 定期更新修補漏洞
3. 網路服務需要認證
4. 使用防火牆限制存取

I3：Insecure Ecosystem Interfaces

中文：不安全的生態系介面

問題： IoT 設備通常連接到手機 App、雲端平台、API 等。這些介面的安全問題會影響整個系統。

常見問題：

• Web 管理介面有 XSS、SQL Injection
• API 沒有認證或認證薄弱
• 手機 App 儲存敏感資料不安全

防護措施：

1. 套用 OWASP Top 10 和 API Top 10 標準
2. 所有介面都要認證授權
3. 輸入驗證和輸出編碼

I4：Lack of Secure Update Mechanism

中文：缺乏安全更新機制

問題：

• 沒有韌體更新功能
• 更新沒有加密傳輸
• 更新檔沒有簽章驗證
• 沒有防止降級攻擊

攻擊情境：

攻擊者攔截韌體更新流量
植入惡意程式碼
設備下載並安裝惡意韌體
設備成為殭屍網路一員

防護措施：

1. 更新必須加密傳輸（HTTPS）
2. 韌體必須數位簽章
3. 驗證韌體完整性
4. 防止版本降級
5. 支援自動更新

I5：Use of Insecure or Outdated Components

中文：使用不安全或過時的元件

問題：

• 使用有已知漏洞的函式庫
• 作業系統版本過舊
• 沒有更新第三方元件

防護措施：

1. 建立 BOM（Bill of Materials）清單
2. 監控元件漏洞公告
3. 定期更新元件
4. 淘汰不再維護的元件

I6：Insufficient Privacy Protection

中文：隱私保護不足

問題：

• 收集過多使用者資料
• 資料儲存和傳輸沒有加密
• 沒有告知使用者資料用途
• 資料保留過久

防護措施：

1. 資料最小化原則
2. 加密敏感資料
3. 透明的隱私政策
4. 提供資料刪除選項

I7：Insecure Data Transfer and Storage

中文：不安全的資料傳輸和儲存

問題：

• 敏感資料明文傳輸
• 本地儲存沒有加密
• 金鑰管理不當

防護措施：

1. 使用 TLS 加密所有傳輸
2. 本地資料加密
3. 安全的金鑰儲存

I8：Lack of Device Management

中文：缺乏設備管理

問題：

• 無法遠端管理設備
• 無法監控設備狀態
• 無法追蹤資產
• 缺乏日誌記錄

企業 IoT 部署需要：

1. 設備清單管理
2. 遠端設定和更新
3. 安全監控和告警
4. 設備除役流程

I9：Insecure Default Settings

中文：不安全的預設設定

問題：

• 預設開啟不必要功能
• 預設密碼太簡單
• 預設權限太寬鬆
• Debug 模式預設開啟

防護措施：

1. 安全預設原則
2. 關閉非必要功能
3. 強制設定流程
4. 提供安全設定指南

I10：Lack of Physical Hardening

中文：缺乏實體安全防護

問題：

• 暴露的除錯介面（UART、JTAG）
• 沒有防拆機制
• 可以輕易讀取韌體
• 沒有安全開機（Secure Boot）

防護措施：

1. 移除或停用除錯介面
2. 防拆偵測
3. 加密儲存
4. 實作 Secure Boot

---

IoT 安全測試方法

IoT 安全測試需要多層面的評估。

測試範圍：

層面	測試重點
硬體	實體介面、除錯埠、儲存媒體
韌體	更新機制、加密、寫死密碼
網路	開放服務、加密、認證
Web/App	標準 Web/Mobile 安全測試
API	認證、授權、輸入驗證
雲端	資料安全、存取控制

常用工具：

工具	用途
Binwalk	韌體分析和提取
Firmwalker	韌體安全掃描
Nmap	網路服務掃描
Wireshark	網路流量分析
Bus Pirate	硬體介面分析
OWASP ZAP	Web/API 掃描

韌體分析範例：

# 使用 Binwalk 提取韌體
binwalk -e firmware.bin

# 搜尋寫死的密碼
grep -r "password" _firmware.bin.extracted/
grep -r "secret" _firmware.bin.extracted/

# 尋找 SSH 金鑰
find _firmware.bin.extracted/ -name "*.pem"
find _firmware.bin.extracted/ -name "id_rsa"

IoT 產品上市前需要資安檢測？我們能幫忙

---

常見問題 FAQ

Q1：iOS 和 Android 哪個比較安全？

兩者各有優劣，沒有絕對答案。

iOS 的安全優勢：

• 封閉生態系，App 審核嚴格
• 系統更新覆蓋率高
• 硬體與軟體整合的安全機制
• 沙箱隔離較嚴格

Android 的安全優勢：

• 開源，可以檢視安全機制
• 更細緻的權限控制
• 企業管理功能豐富
• 可以安裝安全 App（防毒、VPN）

實際風險比較：

• iOS 裝置較少被惡意程式攻擊
• Android 惡意程式較多（因為市佔率高、可側載）
• 兩者都有被國家級攻擊的案例
• App 本身的安全比平台更重要

結論：選擇任一平台，保持系統更新、只安裝可信 App、注意權限授予，比選哪個平台更重要。

Q2：如何檢測 App 是否安全？

一般使用者可以做的：

1. 只從官方商店下載 App
2. 檢查 App 要求的權限是否合理
3. 查看使用者評價和評分
4. 確認開發者資訊
5. 注意 App 的隱私政策

開發團隊應該做的：

1. 使用 MobSF 進行自動化掃描
2. 依照 OWASP MASVS 檢查清單
3. 進行程式碼審查
4. 委託專業滲透測試
5. 定期重新評估

App 安全的檢查指標：

• 通訊是否加密（看是否使用 HTTPS）
• 是否有實作 Certificate Pinning
• 本地資料是否加密儲存
• 認證機制是否安全
• 是否有防逆向工程措施

Q3：智慧家電需要擔心資安嗎？

需要，而且很重要。

智慧家電的資安風險：

1. 隱私風險：攝影機、麥克風可能被駭入
2. 成為跳板：攻擊者可從 IoT 裝置進入家庭網路
3. 殭屍網路：被用於發動 DDoS 攻擊
4. 勒索軟體：智慧鎖被駭可能被鎖在門外

真實案例：

• 智慧攝影機被駭入直播家庭畫面
• 智慧音箱被用於竊聽對話
• 智慧電視被植入廣告軟體
• 連網的嬰兒監視器被陌生人存取

保護建議：

1. 購買前研究品牌的安全紀錄
2. 修改預設密碼
3. 定期更新韌體
4. 將 IoT 裝置放在獨立的網路區段
5. 關閉不需要的遠端存取功能
6. 不再使用時，執行設備重置

---

結論

Mobile 和 IoT 設備的安全挑戰和傳統 Web 應用不同，需要專門的安全思維。

Mobile 安全重點：

• 資料儲存要加密
• 通訊要 Certificate Pinning
• 認證授權在伺服器端驗證
• 防止逆向工程和程式碼竄改
• 遵循 MASVS 標準

IoT 安全重點：

• 消滅預設密碼
• 建立安全更新機制
• 最小化攻擊面
• 全生態系都要考量
• 實體安全不能忽略

下一步建議：

• 用 MASVS 檢查你的 App 安全等級
• 盤點你環境中的 IoT 設備
• 確認所有設備的韌體都是最新版本
• 規劃 IoT 設備的網路隔離

如果你正在開發 AI 驅動的 Mobile 或 IoT 應用，也要留意 OWASP LLM Top 10 的風險。實戰練習方面，Juice Shop 是很好的起點。

插圖：對比圖左側顯示手機圖示代表 Mobile 安全（列出 MAS...

場景描述： 對比圖左側顯示手機圖示代表 Mobile 安全（列出 MASVS、MASTG、MobSF 關鍵字），右側顯示智慧家電圖示代表 IoT 安全（列出韌體更新、預設密碼、網路隔離關鍵字）。中間以 OWASP 標誌連接。

視覺重點：

• 主要內容清晰呈現

必須出現的元素：

• 依據描述中的關鍵元素

需要顯示的中文字： 無

顏色調性： 專業、清晰

避免元素： 抽象圖形、齒輪、發光特效

Slug: mobile-iot-security-comparison

預約資安評估，讓專家用 OWASP 標準檢視你的 App 與 IoT 產品