此文早前發佈於致點科技創始人個人博客，專此轉載並有所修改。

一、前言

OWASP Top 10 2025 第六項風險「Insecure Design」（不安全設計）正是軟件工程界與網絡安全界真正交匯之處，卻亦是雙方最容易互相推卸責任、選擇性忽略的「灰色地帶」。

網絡安全從業員往往將此歸咎為「開發團隊的問題」，理由是針對直接關聯業務邏輯的不安全設計，網絡安全常用的「外科手術式」技術手段基本上無能為力；而軟件工程師則慣性認為：「即使設計有問題，那也是業務需求使然，並非漏洞」，潛台詞即是業務優先、安全靠邊。

正因如此，A06 風險長期存在，根源在於雙方認知分歧，且均未能穿透問題本質。

Insecure Design 的本質，絕非單純以編碼缺陷可概括。它是一種在需求分析階段便已埋下的結構性風險，關鍵在於執行需求分析的系統分析師是否具備足夠的風險管控意識，以及能否從業務邏輯中預判潛在威脅因素，繼而才能在設計與實現階段作出協同應對。

二、導致不安全設計的典型情境

筆者在此舉出親身經歷的兩個案例：

1）經驗慣性所致

在工業物聯網（IIoT）領域，常見的設計慣性是：由於設備通常部署於物理隔離的內網環境，開發人員習慣將控制指令（如啟停、參數調整）以明文形式直接在網絡上傳輸。此類設計雖在封閉網絡中隱患尚存，但因攻擊面受限，仍屬「可控風險」。

然而，當同一設計邏輯被直接套用至面向互聯網的消費級 IoT 系統時，不可控風險隨即浮現。攻擊者可透過列舉 API 路徑、重放請求、篡改參數等方式，繞過身份驗證，直接操控設備。

舉例而言，假設某設備的 API 設計如下：

POST /api/v1/device/12345/control
Body: { "action": "set_max_op_mins", "value": 30 }

若 API 內部未對 URL 路徑中的設備 ID（12345）實施適當的存取控制措施——例如驗證用戶身份、權限，或要求訪客提供有效存取密鑰（顯然本例並無此機制）——攻擊者便可能透過窮舉法獲取設備 ID，進而構造控制參數，遠程操縱設備，造成設備損毀與經濟損失。

須強調的是，若設計階段根本未考慮任何權限控制機制，這並非「越權存取」，而是根本未建立權限模型，屬於典型的 Insecure Design。透過源代碼審計即可確認此問題性質。

此問題的根源不在開發者的編碼能力高低，而在於經驗慣性導致系統設計時未將「資源歸屬」與「操作授權」視為業務邏輯的核心規則納入業務模型。

2）具潛在風險的業務模型

除違反明確風險控制原則所引致的安全漏洞外，Insecure Design 還有一種更隱蔽的情況：

業務邏輯模型本身即構成風險。

此類問題不易察覺，卻尤需在分析階段便前瞻性識別，否則問題將延至設計、實現甚至交付後才暴露，屆時或已難以收拾。

例如，某 O2O 網上預訂流程的業務邏輯被設計為一系列用戶步驟，每步對應一個 API 操作：

選擇線下門市 → 選擇服務類型 → 選擇服務細節參數 → 選擇預訂時間 → 選擇付款方式 → 發起付款 → 付款後處理等。每個環節至少對應一個 API。

單從業務邏輯看，這些步驟看似必要，能有效引導用戶完成整個線上服務流程，API 設計緊貼業務邏輯，似乎「合理」。

但從風險管控角度觀之，此設計等於將風險敞口擴大 N 倍（N = API 數量）。只要其中任一 API 存在安全漏洞，整個系統即告失守。

三、從軟件工程角度探討解決方案

上述兩例均無法依靠「外科手術式」技術手段彌補，必須從軟件工程開發本質著手解決。

針對案例一：混淆 API 參數，並設計合適的鑑權機制。

自然有人會質疑：「混淆參數增加複雜度與工作量，真有必要？」

答案是肯定的。須強調，混淆（Obfuscation）僅是實現機密性（Confidentiality, C）的手段之一。資訊安全的 CIA 三要素（Confidentiality, Integrity, Availability）必須協同保障。

• 如何確保完整性（Integrity）？
  可對 API Payload 進行數位簽章與驗證，或僅對關鍵 ID 參數使用 HMAC 校驗，防止篡改。
• 如何保障可用性（Availability）？
  混淆機制不宜過度複雜，以免引入效能瓶頸或調試困難。例如，若數位簽章僅需 10 分鐘內有效，則無需使用長密鑰或多演算法交叉驗證。

業界已有成熟模式可循，如 JWT（JSON Web Token）可直接採用，或簡化為外部 ID 映射內部 ID。但如前所述，必須結合 CIA 三要素的綜合評估結果方能定案。

針對案例二：取消原有分步 API，改為單一「獲取服務內容」API。所有步驟在前端完成，僅在發起付款時提交完整訂單，由後端 API 進行全面校驗。

此方案之核心，在於軟件工程人員需在分析與設計階段深入理解業務邏輯，思維不能拘泥於既有分步流程，並意識到新設計更能靈活適應未來流程變更：

前期大部分業務邏輯由前端處理，若需調整步驟以提升用戶體驗，大概率無需修改後端 API，反而提升了 API 的健壯性。

事實上，從軟件工程角度看，安全設計所帶來的額外實現成本，不能簡單以「值不值得」衡量。正如「資料庫讀寫是否需交易機制」、「系統是否需日誌審計」等基礎議題一樣，安全並非可選項，而是軟件品質屬性之一。作為系統分析師或架構師，我們的職責是在需求階段即將安全視為非功能性需求，並量化其對系統可靠性與合規性的影響。

四、從網絡安全角度重新解讀 Insecure Design

不少安全從業員仍將 Insecure Design 簡單等同於「越權漏洞」（Broken Access Control），此乃誤解。

Insecure Design 的本質是「未限制風險的產生」。

越權的前提是存在權限模型，而 Insecure Design 的範疇廣闊得多。即使僅從資源所有權關係、角色操作映射等要素理解，仍屬片面，未能從整體風險管控視角把握其本質。如前述案例二所示，風險敞口倍增問題正是整體性風險控制缺失的體現。

安全從業員之所以存在此局限，多因安全與業務脫節所致。筆者於過往文章中屢次強調：

若安全未能融入業務，必將被邊緣化，甚至遭徹底忽視。

對企業高層而言，CIO 與 CISO 是否應為兩個分離角色？筆者的答案是否定的。

具體至執行網絡安全職責之人員，若未能將職能與能力延伸至業務相關的系統設計文件、數據流圖、權限模型及功能流程的安全審查，即代表其仍未與業務融合。

五、安全設計無捷徑，不可迴避

軟件開發中最危險的思維莫過於：「先跑通功能，安全日後再加。」

此種「敏捷式拖延」在 Insecure Design 面前尤為致命。一旦數據模型、介面規範、權限體系定型，後期修改將牽一髮而動全身，所需成本遠高於初期設計階段。

順帶一提，此亦影響經濟審計（筆者背景之一）：

一個因安全漏洞而需「補鑊」的應用系統，其實際價值並不會因追加修補投資而增值，反而因確認存在重大缺陷而應予減值。

尤其在涉及知識產權定價與轉讓時，等於直接否定其價值。誰願冒險採購一套曾耗巨資修補漏洞的系統？誰能保證其中沒有其他未被發現的重大風險？

因此，Secure by Design 的核心在於：

安全不是系統功能，而是原則性的整體系統能力。

它要求我們在繪製第一張 UML 圖、撰寫第一個 Use Case 時，便貫穿風險管控意識。

系統分析師，必須是網絡安全落地的第一環。

六、網絡安全從業員何去何從？

本文雖源於筆者自身技術背景（資訊系統審計師 + 系統分析師 + 軟件工程碩士），但對純網絡安全從業員亦具啟示：

未來的安全人才，必須立足於「軟件工程與網絡安全」的交叉點。

僅會用 Burp Suite 爆破 API 的時代正在過去——AI 正迅速取代機械重複的勞動。企業真正需要的，是能解讀架構圖、參與需求評審、推動威脅建模落地的「橋樑型」人才，或更直白地說：能判斷某項設計是否引入不可接受風險的人才。

因為，安全已是現代軟件工程不可分割的一部分。