D-20260703-01｜CSP 交付＝build 時 meta 注入＋connect-src scheme 級白名單

背景與驅動力

部署資訊首輪複審撞出三方衝突：GitHub Pages 不能設自訂 HTTP header，原 CSP_HEADER 在主站根本無法交付；而 connect-src 若採固定域名白名單，又與「玩家可自選 signaling／pinning／bootstrap 節點」衝突——P2P 對端本質上不可枚舉。

考慮過的選項

• 維持 HTTP header 交付：靜態託管做不到、規則空轉（未採）。
• connect-src 固定域名白名單：封死玩家的節點選擇權（未採）。
• build 時 meta 注入 ＋scheme 級放寬（採納，使用者確認放寬）。

決定

• CSP 改 build 時生成 <meta> 標籤注入 index.html（常數 CSP_HEADER 改為 CSP_META）。
• connect-src 放寬為 scheme 級白名單 'self' wss: https:——節點選擇權的必要代價，仍擋非 TLS 外連。
• 已知風險接受並明文：meta CSP 不支援 frame-ancestors、GitHub Pages 無法送 X-Frame-Options＝ 主站無框架保護；可接受依據 ＝ 無 cookie、無跨源授權狀態。HTTPS 由 github.io HSTS preload 與 custom domain enforce-HTTPS 承擔。

後果與影響

CSP 從部署層假設收斂為 build 產物的一部分，權威在 security.md，資安規範.md 與 部署資訊.md 同步鏡像。scheme 級 connect-src 是玩家自選節點模型的長期前提；框架保護缺位為記錄在案的接受型風險，若未來主站出現 cookie 或跨源授權狀態需重審。