什麼是 JSON 注入攻擊？

JSON 注入（JSON Injection）指攻擊者透過在 JSON 格式的輸入中插入惡意字元或結構，讓伺服器在反序列化（deserialization）時執行非預期的行為。與 SQL 注入不同，JSON 注入的目標是破壞客戶端或伺服端的資料解析邏輯，而非直接操作資料庫。

最常見的攻擊手法是在 JSON 字串中插入控制字元，例如在用戶名稱欄位埋入 \"admin\":true，讓系統在解析時意外提升權限。

為何 2026 年仍有系統受害？

多數開發者誤以為「只要用 JSON.parse（）就安全」，但事實上：

缺乏嚴格的輸入驗證讓攻擊Payload 直接進資料庫
不信任的第三方 API 回傳資料未做二次驗證就直接入庫
部分框架預設關閉了安全相關的 deserialization 保護

想建立完整的縱深防禦，可參考[如何在 2026 年強化網站資安的三道防線](https://fordige.com/blog/website-security-ai-era-real-battle)。

三種常見攻擊模式

1. 值篡改（Value Tampering）

攻擊者修改 JSON 欄位值，例如在電子商務表單中將 \"price\":100 改為 \"price\":1。若伺服器直接信任客戶端傳來的價格，就形成漏洞。

// 受害範例：直接信任客戶端資料
const order = JSON.parse(clientData);
db.orders.insert({ price: order.price }); // 可被篡改
// 正確做法：伺服器重新計算價格

const product = await db.products.findById(order.productId);

const finalPrice = product.price; // 不信任 clientData

2. 鍵名注入（Key Injection）

在 JSON 物件中注入額外鍵值對，例如在多租戶系統中埋入 "role":"admin"，試圖提升自己的權限等級。

// 受害範例

const userInput = JSON.parse(userData);

Object.assign(currentUser, userInput); // 攻擊者可注入任意鍵
// 正確做法：白名單欄位過濾

const allowedKeys = ["name", "email", "avatar"];

const sanitized = allowedKeys.reduce((acc, key) => {

if (key in userInput) acc[key] = userInput[key];

return acc;

}, {});

3. 原型鏈污染（Prototype Pollution）

透過 proto 或 constructor 屬性影響物件原型，可能導致遠端程式碼執行（RCE）。Node.js 應用特別容易受害。

// 典型 Prototype Pollution Payload

{\n  "proto": {\n    "isAdmin": true

}

}
// 防護：禁止可預測的屬性名稱

const FORBIDDEN = ["proto", "constructor", "prototype"];

function safeParse(json) {

const obj = JSON.parse(json);

FORBIDDEN.forEach(k => delete obj[k]);

return obj;

}

## 三層防護實戰

第一層：輸入驗證（Input Validation）

所有來自客戶端的 JSON 都視為不可信任。使用 JSON Schema 做嚴格型別驗證，而非只做字串檢查。

const Ajv = require("ajv");

const ajv = new Ajv({ allErrors: true, strict: false });
const schema = {

type: "object",

properties: {

username: { type: "string", minLength: 2, maxLength: 50, pattern: "^[\w]+$" },

email: { type: "string", format: "email" },

age: { type: "integer", minimum: 0, maximum: 150 }

},

required: ["username", "email"],

additionalProperties: false

};
const validate = ajv.compile(schema);

const valid = validate(userData);

if (!valid) throw new Error("Invalid input: " + validate.errors.map(e => e.message).join(", "));

第二層：輸出編碼（Output Encoding）

當 JSON 資料要輸出到 HTML 或其他上下文時，必須做上下文感知編碼（Context-Aware Encoding），防止 XSS 與二次注入。

// 使用 DOMPurify 淨化可能包含 HTML 的 JSON 欄位

const DOMPurify = require("isomorphic-dompurify");
function sanitizeForHTML(obj) {

return JSON.parse(

DOMPurify.sanitize(JSON.stringify(obj), { RETURN_DOM: false })

);

}

第三層：安全的 Deserialization

使用 JSON.parse() 而非 eval() 或其他不安全的反序列化函式。Node.js 環境建議使用 safe-json-parse 或自訂try-catch 包裝。

// 安全解析函式

function safeJsonParse(str) {

try {

return { success: true, data: JSON.parse(str) };

} catch (e) {

return { success: false, error: e.message };

}

}
// 使用 Result Pattern

const result = safeJsonParse(untrustedData);

if (!result.success) {

logger.warn("JSON parse failed: " + result.error);

return res.status(400).json({ error: "Invalid JSON" });

}

## 真實案例：電子商務價格篡改

2025 年某台灣電商平台被發現允許客戶端直接傳送商品價格，攻擊者可透過修改 JSON 中的 discount_price 欄位以 1 元購買高單價商品。修復方式為：伺服器根據 product_id 重新查樣計算價格，完全不信任客戶端傳來的任何金額欄位。

這個案例說明了一個核心原則：所有業務邏輯相關的數值，都必須在伺服器端根據已知的事實重新計算，而不是信任客戶端聲稱的數字。

工程師自我檢查清單

✅ 所有 API 輸入都有 JSON Schema 驗證？
✅ 禁止 __proto__、constructor、prototype 進入反序列化流程？
✅ 第三方 API 回傳資料有做二次驗證？
✅ 業務邏輯相關數值（價格、庫存、權限）有伺服器端重新計算？
✅ 使用 JSON.parse() 而非 eval() 或 Function()？
✅ 有啟用 Content-Type: application/json 檢查，防止 MIME type 混淆攻擊？

## 結語

JSON 注入不像 SQL 注入那樣眾所皆知，但攻擊後果同樣嚴重——從價格篡改、權限提升到原型鏈污染導致 RCE，每一個都是真實風險。2026 年的防護不再是「有沒有做驗證」的問題，而是「驗證夠不夠嚴格」的問題。JSON Schema 白名單驗證加上業務邏輯的伺服器端重算，是多數應用場景的最低防護標準。

## 延伸閱讀

・當 AI 變成破口：Prompt Injection 攻擊的真實威脅與 OpenClaw 資安實踐
Prompt Injection 和 JSON Injection 同屬 injection 攻擊 family，防護思路相近，都是「驗證優先於執行」的原則

・網站資安課：破解 JSON-LD 注入與檔案上傳偽裝
同作者系列文章，涵蓋網站資安的多種攻防面向，JSON 注入是其中一個重要章節

・網站開發方案與資安顧問報價
網站資安不是一次性的功能，而是需要持續經營的系統，歡迎聯絡鍛碼匠評估你的資安需求與實作方案

JSON 注入的防護看起來是工程細節，但對於網頁設計公司來說，這關乎你交付的網站是否真的安全。攻擊者利用 JSON 輸入欄位滲透伺服器的案例並不少見——從價格篡改導致商家損失、到原型鏈污染導致系統被接管，每一個都是可以在開發階段就避免的風險。鍛碼匠在替客戶建置網站時，輸入驗證、輸出編碼、和業務邏輯的伺服器端重算，是每個專案都會執行的基本資安標準。

缺乏嚴格的輸入驗證讓攻擊Payload 直接進資料庫
不信任的第三方 API 回傳資料未做二次驗證就直接入庫
部分框架預設關閉了安全相關的 deserialization 保護