預設 Redaction Rule

SDK 內建的 redaction rule 覆蓋最常見的敏感欄位模式。開發者不需要設定就能獲得基本保護。

欄位名稱比對

以下欄位名稱（不分大小寫）的值自動替換為 [REDACTED]：

• password、passwd、secret、token、api_key、apiKey
• authorization、auth、credential
• ssn、social_security
• credit_card、card_number、cvv、cvc

欄位名稱比對用 substring match — user_password 包含 password 會被 redact，password_reset_token 包含 password 和 token 也會。

值格式比對

以下格式的值無論欄位名稱為何都自動替換：

• Email 地址格式（user@domain.com → u***@domain.com）
• 信用卡號碼格式（連續 13-19 位數字 → 保留末四碼）
• Bearer token 格式（Bearer xxx → Bearer [REDACTED]）

值格式比對用正則表達式。正則的效能影響在大量事件時需要注意 — 預設 rule 的正則保持簡單，避免 catastrophic backtracking。

自訂 Pattern

應用可能有自己的 secret 格式，預設 rule 覆蓋不到。SDK 提供 API 讓開發者註冊自訂 redaction pattern。

 1monitor.addRedactionRule(
 2  name: 'internal-api-key',
 3  pattern: RegExp(r'sk_live_[a-zA-Z0-9]{24}'),
 4  replacement: '[REDACTED:api-key]',
 5)
 6
 7monitor.addRedactionRule(
 8  name: 'database-url',
 9  fieldNames: ['database_url', 'db_url', 'connection_string'],
10  replacement: '[REDACTED:db-url]',
11)

自訂 pattern 的設計考量：

Pattern 在 init 時註冊。Redaction rule 在 SDK 初始化時設定，之後所有事件都通過這些 rule。不支援動態修改 — 避免「中途加 rule 導致之前的事件沒被 redact」的困惑。

Pattern 順序無關。所有 rule 獨立執行，不依賴順序。一個欄位可以匹配多個 rule，以第一個匹配的 replacement 為準。

Replacement 可以保留部分資訊。[REDACTED] 完全遮蔽，[REDACTED:api-key] 保留類型資訊，u***@domain.com 保留結構。保留類型資訊對 debug 有幫助 — 看到 [REDACTED:api-key] 至少知道這裡原本有一個 API key。

Redaction 的適用範圍

Redaction 應用在 SDK 送出事件前的最後一步 — 在序列化（JSON encode）之前。適用範圍包括：

• Event 的 data 欄位（自由欄位，開發者可能放入任何內容）
• Error 的 stack trace（檔案路徑可能包含使用者名稱或部署路徑）
• Error 的 message（例外訊息可能包含 query string 或參數值）
• Lifecycle 的 metadata（連線 URL 可能包含認證資訊）

Redaction 不應用在 SDK 的內部欄位（timestamp、event type、session ID）— 這些是 SDK 自己產生的，不包含使用者資料。

下一步路由

• 資料離開 client 後的保護 → Transport 安全
• 去識別化策略 → 去識別化策略
• IME 個人化學習的 secret 洩漏風險 → ux-design 模組三 IME 安全 checklist

概念位置

Redaction 位在 SDK 端的事件產生和 collector 端的事件接收之間。它是監控資料安全的第一道防線 — 在資料離開使用者裝置之前處理，比 collector 端的 access control 更早介入。Redaction 和 transport 加密（HTTPS）互補：redaction 保護欄位內容，transport 加密保護傳輸過程。

可觀察訊號與例子

系統需要 redaction 的訊號是監控事件的 data 欄位可能包含使用者輸入。CLI 輸入可能含密碼（mysql -p'secret'）、API key（Authorization: Bearer sk-...）、連線字串（含帳密的 URL）。IME 個人化學習也是洩漏面 — 輸入框的內容被 IME 學習後跨 app 可見。

設計責任

Redaction 要定義預設規則（哪些欄位名稱自動 redact）、自訂 pattern（正則表達式比對敏感值）、執行時機（event 進入 buffer 前還是 flush 時）、以及 redaction 失敗的處理（丟棄整筆事件 vs 只移除敏感欄位）。

預設 redaction rule

SDK 內建一組預設 rule，處理常見的敏感資訊 pattern：

密碼欄位

匹配 data 物件中 key 包含 password、passwd、secret、token、api_key、apiKey、authorization 的欄位。匹配方式是 key 名稱的子字串比對（case-insensitive）。

URL 中的認證資訊

匹配 https://user:password@host 格式的 URL，把 user:password 部分替換為 [REDACTED]。

Stack trace 中的檔案路徑

匹配 stack trace 字串中的使用者目錄路徑（/Users/username/、/home/username/、C:\Users\username\），替換為 [USER_HOME]/。避免使用者名稱從 stack trace 洩漏。

自訂 redaction rule

業務特定的敏感資訊（信用卡號、身分證字號、醫療資料）不在預設 rule 的範圍內。SDK 提供 API 讓開發者在 init 時註冊自訂 rule。

1Monitor.init({
2  redactionRules: [
3    { pattern: /\b\d{4}[-\s]?\d{4}[-\s]?\d{4}[-\s]?\d{4}\b/, replace: '[CARD]' },
4    { keyPattern: /^ssn$/i, replace: '[REDACTED]' },
5  ],
6})

自訂 rule 和預設 rule 一起執行。如果同一個值被多個 rule 匹配，第一個匹配的 rule 生效（rule 的執行順序：預設 rule 先，自訂 rule 後）。

Redaction 的執行時機

Redaction 在事件進入 flush payload 的那一刻執行 — buffer 中的事件保持原始內容，flush 時複製一份並在複製上執行 redaction。

在 buffer 中保持原始內容的理由是 debug：開發者在本地 console 看到的 log 應該包含完整資訊（開發環境不需要脫敏），只有離開 SDK 時才脫敏。SDK 可以提供 debugMode flag — debugMode 開啟時 console log 印出原始內容，HTTP POST 仍送出脫敏後的內容。

Redaction 和模組七的關係

SDK redaction helper 是模組七 資安與隱私中 redaction 策略的實作層。模組七定義「什麼資訊需要被保護」（策略），本章定義「SDK 如何在程式碼中實現這個保護」（實作）。

兩者的分工：

Collector 端可以做第二道檢查（re-scan 收到的事件是否仍包含敏感 pattern），作為 SDK 端 redaction 的備援。但主要的脫敏責任在 SDK 端 — 資料離開 SDK 後經過網路，已經暴露在傳輸風險中。

下一步路由

• SDK 公開 API → SDK 公開 API 設計
• 資安與隱私的完整策略 → 模組七 資安與隱私
• 自動攔截的 error 也需要 redaction → 自動攔截機制

待寫章節

• SDK redaction API 設計（預設 redaction rule + 自訂 pattern）
• Transport 安全（HTTPS / basic auth / 同區網也要加密的理由）
• Collector access control 實作（認證 / 授權 / access log）
• 去識別化策略（IP 截斷 / user agent 簡化 / stack trace 路徑清理 / session UUID）
• GDPR 最小化原則的工程落地
• 「監控資料洩漏」的 threat model
• Client-side SDK 認證的根本限制（credential 必然暴露、多層緩解策略）

跨分類引用

• → backend 07 資安：server-side 的 secret management 跟本模組的 redaction 互補
• ← ux-design 模組三 輸入機制：IME 個人化學習 = secret 洩漏
• ← testing 模組二 客戶端可觀測性：log 內容可能含 secret，需要 redaction
• → monitoring 模組八：去識別化是商業利用的入場條件
• 待建連結 → compliance/（隱私法規教學分類）