OWASP Top 10 for LLM Applications 全覽
查核資訊： 本文於 2026-08-05 依 OWASP GenAI Security Project 官方文件初次查核，並於 2026-08-12 完成最終查核。內容以官方資源頁提供的 OWASP Top 10 for LLM Applications 2026 為準。資源頁標示 August 3, 2026；初次查核時的封面縮圖顯示 Version 2026、August 4th, 2026。最終查核時，官方 PDF 的 publication date 欄位已改為待定，因此日期差異只代表官方網站版本交接時的歷史快照，8 月 4 日不是唯一可驗證的正式發布日。初次與最終查核時，官方
genai.owasp.org/llm-top-10/著陸頁仍停留在 2025 版，且明說沒有新版；2026 版則由資源頁提供。條目與緩解建議會隨版本演進，引用前請自行確認當下版本。
查 OWASP 清單之前，我先逼自己回答一個問題：不看任何資料，我認為 LLM 應用最重要的風險是什麼？
我列出三條：prompt 注入、權限過大、透露過多資訊。並且預測：官方十條裡，大概七條會落在前兩篇的結論——最小權限、後端授權、sink 驗證——這個範疇。（sink 指資料最後真正被使用的地方，例如送進 SQL、瀏覽器或交給人閱讀；本文用到的專有名詞，下面有一張對照表。）
然後我去對答案，先撞到一件跟內容無關、但更值得先講的事。
查核資訊時，官方網站正處於版本交接
我一開始查的是官方著陸頁。著陸頁列出 2025 十條，還明白告訴我沒有更新版本，所有單一條目頁也都是 2025。
同一時間，2026 版已經出現在官方資源頁，但著陸頁還沒跟上。資源頁標示 August 3, 2026；我在 2026-08-05 擷取的頁面中，封面縮圖顯示 Version 2026、August 4th, 2026。我是在追別的問題時才撞見那個網址，回頭抓 PDF 才發現整份清單重排過。
兩張截圖是同一天、同一個官方網站，相隔幾次點選。著陸頁那張用肯定句告訴你這是最新版，資源頁的頁面日期與封面縮圖日期卻不一致。2026-08-12 最終查核時，官方 PDF 的 publication date 欄位又改為待定。這些日期只能說明當時頁面的呈現狀態，不能單獨當成唯一正式發布日。
如果我只信著陸頁，這篇文章會建立在一份已被資源頁上 2026 版取代的清單上，而且會附帶一句「官方沒有預告新版」的錯誤保證。這次的落差本身就是可帶走的教訓：**查框架版本時，著陸頁可能落後正式發布，而且著陸頁會用肯定句告訴你沒有新版。**讀者要查的是發布清單，不能只看導覽頁。
先把名詞講清楚
接下來的十條會密集出現幾個專有名詞。這些名詞在後面二十幾篇還會反覆用到，所以先在這裡一次講清楚，讀者不必為了看懂一條風險而中斷去查別的資料。
| 名詞 | 在這篇文章裡的意思 |
|---|---|
| sink | 資料最後真正被使用的地方，例如送進 SQL、HTML、shell、Email，或直接交給人閱讀。資安上的通則是：不可信資料抵達 sink 之前，必須先依那個 sink 的規則處理過。 |
| token | 模型讀寫文字的最小單位。模型看到的是一長串 token，system prompt、使用者輸入與檢索到的文件在這一串裡沒有型別上的差別。 |
| context | 這一次請求交給模型的全部文字，包含 system prompt、對話紀錄、檢索到的資料與工具說明。 |
| system prompt | 開發者預先寫好、每次請求都附在最前面的指示，用來規定模型的角色與行為。 |
| RAG | 檢索增強生成。系統先從外部知識庫查出相關片段，再連同使用者問題一起交給模型作答。 |
| embedding | 把文字轉成一串數字向量，讓系統能用數學上的距離找出語意相近的內容，是 RAG 檢索的基礎。 |
| 向量資料庫 | 專門存放 embedding 並執行相似度檢索的資料庫。 |
| adapter | 疊在既有模型之上的小型微調權重（例如 LoRA），可以改變模型行為而不必重新訓練整個模型。 |
| agentic | 模型不只回話，還能自行呼叫工具、連續執行多個步驟的用法。 |
| MCP | Model Context Protocol，把 AI 應用串接到外部資料、工具與流程的開放標準。 |
| schema | 描述資料或工具參數長什麼樣子的結構定義。 |
| provenance | 來源履歷：一個模型、資料集或套件從哪裡來、經過誰的手、中途有沒有被改過。 |
| parameterized query | 把 SQL 的語法結構與參數分開送給資料庫的寫法，資料因此不可能被當成語法執行。 |
| XSS／SSRF／RCE | 跨站腳本、伺服器端請求偽造、遠端程式碼執行。在本文討論的情境中，三種結果都可能出現在下游元件沒有依實際 sink 處理不可信內容，讓不可信內容被當成程式碼、指令或資源位置使用。 |
| Denial of Wallet | 攻擊者刻意觸發大量昂貴的推論，把按用量計費的帳單推到無法負擔的程度。 |
官方十條，先對答案
十條沒有增減，但順序大幅重排。最右欄是對照我事前清單的結果：
| 2026 條目 | 一句話講什麼 | 我的直覺 |
|---|---|---|
| LLM01 Prompt Injection | 輸入改變模型行為；官方明講模型不區分指令與資料，指令與資料是同一串 token | 命中 |
| LLM02 Sensitive Information Disclosure | 個資、營業秘密、憑證經由輸出或訓練資料外洩 | 命中（透露過多資訊） |
| LLM03 Excessive Agency | 功能、權限或自主性超過需要，模型做出破壞性動作 | 命中（權限過大） |
| LLM04 Supply Chain | 預訓練模型、adapter、套件與資料集的來源風險 | 完全沒想到 |
| LLM05 Data and Model Poisoning | 預訓練、微調或 embedding 資料被投毒，可植入後門 | 完全沒想到 |
| LLM06 Unbounded Consumption | 推論資源不設限：服務中斷、Denial of Wallet 與模型抽取 | 沒想到 |
| LLM07 Misinformation | 模型產出看似可信的錯誤內容，被人或下游流程當真並據以行動 | 沒想到 |
| LLM08 Hidden Context Exposure | 隱藏的系統指令與 operational context 被提取、推論或重建 | 命中（透露過多資訊） |
| LLM09 Vector and Embedding Weaknesses | RAG 的檢索越權、跨租戶洩漏、embedding 反推與知識庫污染 | 沒想到 |
| LLM10 Improper Output Handling | 模型輸出未經驗證就送進下游，導致 XSS、SSRF、RCE | 沒列，但前篇結論講的就是這條 |
三條直覺對上四條官方條目。「透露過多資訊」拆成兩條：LLM02 是洩漏的內容，LLM08 是特別常見的洩漏位置。
我的直覺剛好撞上這一版最具影響的調整。Excessive Agency 從第 6 升到第 3，官方理由是 agentic 部署才是損害真正發生的地方。而 2025 年的 System Prompt Leakage 改名並擴大成 Hidden Context Exposure，範圍從 system prompt 延伸到開發者指令、RAG 取回的政策文字、工具與函式 schema。官方要求開發者假設隱藏 context 必然會被發現，不要在隱藏 context 裡嵌憑證，也不要單獨拿隱藏 context 當授權邊界。
我的直覺涵蓋的是「請求路徑」
第二個預測得用數的。我把十條的緩解策略逐條讀過，看有幾條最後回到最小權限、後端授權與 sink 驗證。
答案是六條：LLM01 要求最小權限與高風險動作的人工核准；LLM02 要求對資料來源套最小權限；LLM03 的三個根因——功能過多、權限過大、自主性過高——整條就是最小權限的反面清單；LLM08 明確寫著不得把隱藏 context 當成授權或政策執行的邊界；LLM09 的核心緩解策略是 permission-aware 的向量資料庫與 fine-grained 存取控制；LLM10 要求依下游 context 重新編碼，並使用 parameterized query。
第七條要看怎麼算：LLM05 的緩解策略包含沙箱與異常偵測，勉強沾邊，但主體是資料治理。所以我的「七條」預測，嚴格說是六條半。
數字接近不是因為我懂 OWASP，而是因為這六條有共同的形狀：這六條的主要防線都能放回一次請求的路徑上。不可信輸入進來、模型讀到不該讀的資料、模型說了或做了不該做的事。前兩篇建立的原則本來就是為請求路徑設計的，所以這套原則能處理這六條落在請求路徑上的部分，不能取代資料攝取、模型更新等生命週期控制。
盲點不在數量，在軸線
預測失準的四條，錯法比數字有趣。
LLM04 與 LLM05 暴露的是只盯著請求路徑時看不到的風險。LLM04 的模型、adapter、套件與資料集在取得、建置或更新時就可能被掉包；LLM05 則可能發生在預訓練、微調、embedding 建立、RAG 資料攝取與持續學習。LLM04 與 LLM05 的共同點不是都發生在部署前，而是風險會污染跨請求保留的模型、資料或元件，單次請求上的權限控制無法取代來源驗證與資料治理。這兩條構成生命週期軸。
LLM07 的 sink 不是程式，是人的信任，或者信任模型輸出的下游流程。摘要器捏造一段內容不需要任何權限，也不經過任何工具呼叫；只要有人信了、或有流程據以行動，損害就成立。官方把 LLM07 定位成系統層級的失效，而不是使用者不夠謹慎。
LLM06 攻擊的是資源。官方對這條的定性是「成本不對稱」：攻擊者用極低代價觸發不成比例的昂貴運算。官方也點名 MCP 這類工具協定會把單一請求放大成連鎖的下游操作，並直言傳統的請求速率限制已經不夠。
所以這張地圖不是十條平行的風險，而是三條軸線：
- 請求路徑：LLM01、02、03、08、09、10——最小權限、後端授權、sink 驗證在這裡有效。
- 生命週期：LLM04、05——防線是來源驗證、provenance 與資料治理，從部署前延伸到上線後的資料攝取、更新與持續學習流程。
- 資源與信任：LLM06、07——防線是額度、成本上限、輸出查證與介面設計，對象是帳單和人。
同一份清單，兩種分法
我把十條分完三軸才發現，2026 版自己也附了一張分類圖，而且分法跟我不一樣。
我的三軸問的是「這條風險該在系統的哪一層防」。官方那張圖問的是另一個問題：「這條風險在一次攻擊裡負責哪個環節」。官方因此把十條排成同心圓，外圈是攻擊的進入向量，中圈是把災害放大的放大器，正中央是最終造成的影響。
官方那張圖有三個訊息不在條目清單裡
這張圖值得多花一分鐘讀，因為只看十條的名稱看不到下面三件事。
第一，攻擊與防禦的方向相反。 圖的下緣寫著攻擊由外向內流、防禦由內向外推。攻擊者從最外圈任何一個入口進來，一路往核心推進；防守方的順序剛好倒過來，先確定核心那三種影響絕對不能發生，再往外決定每一層要擋掉什麼。這個方向感回答了一個常見問題：十條該先修哪一條沒有標準答案，因為要先決定的不是條目順序，而是你這套系統最不能承受哪一種影響。
第二，中間那一圈是把小事變成大事的機制。 LLM08、LLM09、LLM03 與 LLM10 通常不是攻擊的起點。這四條的作用是放大：把一次成功的注入從「模型講錯話」，變成「資料被送出去」或「危險動作被執行」。官方對 LLM08 的描述就直接寫著，隱藏 context 外洩經常放大 LLM01、LLM02、LLM03 與 LLM10。換句話說，同一次注入最後有多嚴重，取決於中圈這四條被打開了幾條。
第三，虛線代表這一條同時待在不只一層。 中圈那四條全是虛線框。以 LLM03 過度代理為例，LLM03 既可以是放大器，也可以是入口。官方在 LLM03 的內文裡列出幾種觸發情境，其中一種是「先前呼叫過的惡意或已被攻陷的工具」——被攻陷的那個工具本身，就是攻擊起點。
圖說還補了一個例外：不是每一次 LLM04 供應鏈攻擊都要由外往內走，有些直接造成影響。官方沒有舉例。不過 LLM04 涵蓋的狀況包含「取得的模型工件並不是宣稱的那一個」，據此推斷，最直接的情形就是下載到的模型或 adapter 本身已被動過手腳。這種攻擊不需要任何注入，惡意行為在元件裡就已經內建好了。
兩種分法交叉起來
用 LLM02 敏感資訊洩漏當例子最清楚。我把 LLM02 放進請求路徑軸，因為擋住 LLM02 的手段是限制模型讀得到什麼、輸出前再驗證一次，那些手段全都落在一次請求的路徑上。官方把 LLM02 放進最內圈，因為資料真的被洩漏出去時，那已經是攻擊的最終結果，不是攻擊的手法。同一條風險，我問「在哪防」得到請求路徑，官方問「是什麼環節」得到最終影響，兩個答案都對。
把兩種分法交叉排開，十條的落點如下：
| 我的軸線＼官方環節 | 進入向量 | 放大器 | 最終影響 |
|---|---|---|---|
| 請求路徑 | LLM01 | LLM03、LLM08、LLM09、LLM10 | LLM02 |
| 生命週期 | LLM04、LLM05 | — | — |
| 資源與信任 | — | — | LLM06、LLM07 |
生命週期軸的兩條全部落在進入向量，資源與信任軸的兩條全部落在最終影響。我當初分這兩軸時並沒有看過官方這張圖，兩種分法卻把同樣的條目放進同一組，所以這兩軸不是我硬湊出來的分類。
真正分開的只有請求路徑那一軸：這一軸的六條散落在官方的三個環節裡。原因就是 LLM02 那個例子講的——防線位置相同的風險，在攻擊鏈上可以分別是入口、放大器和結果。
兩種分法我都會留著，但使用時機不同。決定要把防禦人力和預算投到哪一層時，我用自己的三軸，因為三軸的每一格都能直接對應到要改的程式或設定。事後要理解一起已經發生的事故時，我用官方那張圖，因為同心圓能較快指出攻擊從哪個環節進來、又在哪裡被放大。
「注入是模型問題」只對了一半
診斷時我把 prompt 注入歸給「模型本身」，其他歸給「系統整合」。讀完官方條目，這個二分法站不住。
LLM01 的成因確實在模型，而且 2026 版把理由講得比我預期更直白：模型在架構上不區分「指令」與「資料」，指令與資料是同一串 token，因此沒有乾淨對應 parameterized query 的機制。前一篇實驗沒有觀察到語意上的攻擊服從，卻撞到另一個量測陷阱：<untrusted_document> 內的 marker 五次都被模型摘要或引用，exact matcher 因而誤報 5／5。這表示自然語言標記與單一字串 matcher 都不能取代系統層的確定性邊界；LLM01 的通用風險判斷仍應以官方條目與更多適應性測試為準，不能由這十次結果單獨推出。
但往下看 LLM01 的緩解策略：限制模型行為、驗證輸出格式、過濾輸入輸出、最小權限、人工核准、隔離標記不可信內容、對抗性測試——沒有一項是「把模型修好」，全部是系統層手段。
修正後的講法是：**成因可以在模型，防線一定在系統。**歸類一個風險時，問「這是誰的錯」沒有行動價值；要問的是「防線放得回哪一層」。
這一版第一次拿事件紀錄檢驗自己的清單
前面幾版排序靠的是從業者投票。2026 版第一次把投票拿去對照真實事件紀錄：蒐集 7,714 筆事件，其中 6,639 筆細節足以分類，最後投票佔四分之三權重、事件資料佔四分之一。
有意思的是分歧出現在哪裡。Prompt Injection 若只按原始事件數排名，會掉出前十。 官方判定這是「防禦效應」——大家防得兇，乾淨的成功利用比較少進到公開資料庫，公開數字因此低估了風險。官方選擇讓投票壓過資料，把 Prompt Injection 留在第一。Misinformation 則相反：投票偏低、事件紀錄偏高，是落差最大的一條，因此往上移。
這個推論陷阱我上一篇才踩過。當時固定 payload 連測五次都失敗，很容易把「這個 payload 沒成功」誤讀成「這個邊界有效」；OWASP 遇到的是同一個陷阱，只是規模放到七千多筆事件。低數字可能代表防守有效，也可能代表你根本沒測到會成功的那一面——分辨這兩種可能，比拿到數字本身更難。
把十條掛回示範應用
地圖要有用，得掛在具體的系統上。我目前的示範應用只有前篇那個最小摘要器：本機 Ollama 跑 gemma4:latest，system prompt 指定摘要任務，輸入是一份不可信文件，輸出是給人讀的純文字。沒有工具、沒有 RAG、沒有機敏資料。
我原本以為這麼小的應用只沾得上一兩條。逐條掛完，六條已經存在或部分存在：
| 條目 | 摘要器現況 | 系列深入篇 |
|---|---|---|
| LLM01 | 已實測但未觀察語意服從：兩組各五次皆為 0／5；標記內 payload 的 exact 5／5 全是摘要或引用造成的誤報 | 第二週整組注入主題 |
| LLM02 | 刻意排除：context 裡沒放機敏資料，無東西可洩；這是控制，不是免疫 | 〈敏感資料防護：PII 偵測與遮罩〉 |
| LLM03 | 刻意排除：不給工具，所以沒有代理可以過度 | 〈Excessive Agency：Agent 的過度代理風險〉 |
| LLM04 | 存在且未處理：gemma4 是從 Ollama registry 拉下來的，我沒有驗證過來源與完整性 |
〈供應鏈風險：模型、套件與 MCP Server〉 |
| LLM05 | 尚未涵蓋：沒有訓練、微調或 embedding 流程 | 〈資料投毒與知識庫污染〉 |
| LLM06 | 部分存在：本機推論沒有帳單，但有算力可被榨取；換成雲端 API 就是 Denial of Wallet | 〈濫用與成本攻擊：DoS、Token 榨取與速率限制〉 |
| LLM07 | 存在：摘要器可能捏造文件裡沒有的內容，讀者信任就是 sink | 系列沒有專篇，先併入輸出端防禦與觀測性兩篇 |
| LLM08 | 存在但低影響：system prompt 只有任務描述，沒有秘密——正好符合官方「風險取決於你放了什麼」的定性 | 〈Hidden Context Exposure：外洩的不只是 system prompt〉 |
| LLM09 | 尚未涵蓋：沒有 RAG 與向量資料庫 | 〈向量資料庫與 Embedding 的安全議題〉 |
| LLM10 | 部分存在：輸出只給人讀，還沒有 HTML 或 SQL 下游；但「給人讀」本身就是 sink | 〈輸出端防禦：過濾、審核與安全渲染〉 |
這張表修正了我的第三個誤判。我以為「掛不上去」代表應用太小，實際上掛完發現兩件事。
第一，LLM04 已經在系統裡了。我下載模型時完全沒想過供應鏈——這正是「完全沒想到」的條目會咬人的方式：供應鏈風險不在我的威脅模型裡，所以我連「沒驗證」這個狀態都沒意識到。
第二，「尚未涵蓋」和「刻意排除」是兩回事。LLM03 掛不上去，是因為我依前兩篇的結論選擇不給工具；LLM05 掛不上去，只是因為還沒做到那裡。地圖的價值就在讓每一個「沒有」變成「刻意沒有」，其餘的標成待辦。
順帶一提，LLM10 的官方條件清單裡有一項值得畫線：會自動抓取模型輸出中外部資源的用戶端渲染器——瀏覽器、聊天介面、IDE、終端機——Markdown 圖片、連結預覽或 iframe 都算，這些渲染器會透過對外請求把 context 資料送出去。也就是說，把輸出「變好看」這個看起來純屬介面的決定，官方直接列為外流條件。
這份清單管到哪裡為止
2026 版還畫了一條我原本沒意識到的邊界：**模型作為應用裡的「元件」時，風險歸這份清單；一旦模型成為「行動者」——能呼叫工具、跨 session 攜帶記憶、在下游造成後果——風險就移交給 OWASP 的 Agentic 清單。**那是另一份獨立的十條，2025 年 12 月公布，涵蓋目標劫持、工具濫用、身分與權限濫用、記憶與 context 污染、代理間通訊、連鎖失效等。
這條邊界剛好把現在的摘要器留在 LLM 清單這一側。但只要哪天我給摘要器工具或記憶，我就得同時看兩份清單，而不是等這一份長出對應的條目。
帶走的判斷
下次拿到任何 LLM 應用——自己的或別人的——我會沿三條軸線問：
- 請求路徑：輸入從哪裡進來、模型讀得到什麼、輸出流向哪些 sink、每個動作誰重新授權？（LLM01、02、03、08、09、10）
- 生命週期：模型、adapter、套件、訓練與檢索資料各自從哪來，來源驗證過沒有？（LLM04、05）
- 資源與信任：推論的用量與成本有沒有上限？誰會不經查證就相信輸出？（LLM06、07）
然後再加一個這次學到的前置動作：先確認手上這份清單是不是最新版，而且不要只問導覽頁。
清單掛完，最大的未解問題是：目前的示範應用小到只能觀察十條裡的一部分。下一篇把實驗環境正式建起來，讓後面的攻擊與防禦每一條都有地方跑。
參考資料
- OWASP Top 10 for LLM Applications 2026（官方 PDF，Version 2026）
- OWASP Top 10 for LLM Applications 著陸頁（查核當下仍為 2025 版）
- OWASP Top 10 for Agentic Applications 發布說明
- OWASP Agentic Security Initiative
- OWASP Top 10 for LLM Applications 2023／24（版本比較用）
- OWASP Static Code Analysis — taint analysis 與 sink 的說明
- Model Context Protocol — 官方介紹
文中兩張網頁截圖擷取自 genai.owasp.org，擷取時間為 2026-08-05；同心圓結構圖為《OWASP Top 10 for LLM Applications 2026》（Version 2026）第 9 頁的 Figure 2，自官方 PDF 原樣取出，未修改圖說或標籤。OWASP 文件與網站內容除另有標示外採 Creative Commons Attribution-ShareAlike 4.0 授權；OWASP 與其標誌為 OWASP Foundation, Inc. 的商標。兩張網頁截圖僅移除第三方朗讀外掛的浮動元件，未修改頁面文字，其中資源頁那張的版本區塊另加放大標示。
本文同步刊載於 iThome 鐵人賽。
《LLM 應用資安：從 Prompt Injection 到 AI Red Teaming》第 3／30 篇
上一篇：傳統資安 vs LLM 資安：到底哪裡不一樣 · 下一篇：打造你的資安實驗室：環境建置