公開デプロイ時の receiver ハードニング（認証・CORS 制限）

[kosako]

背景

receiver は現状ローカルプロトタイプ前提（127.0.0.1、認証なし、CORS *）。EC2 等への公開デプロイを見据えると、閲覧・操作系の面を保護する必要がある。#29 で GitHub token を receiver が持つようになると、攻撃対象としての価値も上がる。

スコープ（管理面の保護）

• inbox / 操作系 endpoint への認証を追加する
  • GET /（inbox）
  • GET /feedback.json
  • GET /screenshots/:file
  • POST /feedback/:id/status
  • POST /import
  • POST /feedback/:id/github-issue（Receiver inbox から GitHub Issue を作成する #29）
  • 最小構成: 共有 token（env / config）+ Bearer or Basic 認証。inbox UI はログインフォームか URL token
• CORS を * から許可 origin リスト（config）に変更する
• HTTPS 終端・bind 先の前提を README のデプロイ節として明文化する（reverse proxy 前提で可）
• secrets（GitHub token / Slack webhook）は env 注入を推奨とし、config ファイル運用との優先順位を明記する

受け入れ条件

• 認証なしで inbox・feedback データ・screenshot にアクセスできない設定が可能
• 許可 origin 以外からの browser fetch がブロックされる
• ローカル開発（認証なし）は引き続きゼロ設定で動く
• README にデプロイ時の設定手順が載っている

関連

• 取り込み面（widget → receiver の POST /feedback）の保護は別 issue（ペア認証・受信データ安全性）で扱う

[kosako]

全体監査(2026-06-20)による確定・追記

本 issue のスコープを独立検証で実在確定（High）。追加の具体情報と、本 issue に含めたい低位ハードニングを記載。

無認証 + CORS *（確定 High）

• setCors が全レスポンスに Access-Control-Allow-Origin: * / Methods: GET, POST, DELETE, OPTIONS を付与（server/receive.js:148-152）。inbound の Authorization 検証はゼロ（L401/L1047 の Authorization はいずれも receiver→外部サービスの outbound）。
• 既定 bind 127.0.0.1（L17）のみが歯止め。reverse proxy 公開時に即露出。
• 誇張の訂正: github-issue の作成先は固定設定 GITHUB_REPO（L400）であり、攻撃者がリポジトリを選べるわけではない。ただし設定済みリポジトリへの無認証 issue 連投（スパム）は依然成立。

本 issue に含めたい監査確定の低位ハードニング

• inbox（GET /）レスポンスに CSP / X-Content-Type-Options が無い（receive.js:652-710）。
• Content-Type / 文字コード検証が無く、非 JSON・非 UTF-8 ボディも JSON 解釈を試みる（receive.js:513-522）。
• 外部 URL（SLACK_WEBHOOK_URL / GITHUB_API_BASE）を検証せず任意ホストへ POST し得る（receive.js:26-36）。※リクエスト本文からは制御できないため実 SSRF ではなく defense-in-depth。
• store の WAL 無効・busy_timeout=0（server/store.js の init() に PRAGMA 無し）→ 共有・多接続時に SQLITE_BUSY で即時失敗。公開／水平展開の前提として PRAGMA journal_mode=WAL; PRAGMA busy_timeout=5000; を設定したい。
• 既知ルートへの未対応メソッドが 405 でなく 404（Allow ヘッダ無し, receive.js:68-123）。

[kosako]

アーキテクチャレビュー(2026-07-02、ローカル ARCH-REVIEW-2026-07-02.md)からの追記 2 点。

🔴 確定所見: RECEIVER_TOKEN 設定時に inbox UI の全操作が 401 で壊れる

server/static/inbox.js の 4 つの操作 fetch(L25 /import、L85 github-issue、L101 status、L124 DELETE)はいずれも Authorization ヘッダーを送っていない。#91 で操作系 endpoint に Bearer 認証を入れたため、トークンを設定した瞬間 inbox の import / status 変更 / 削除 / GitHub Issue 作成がすべて 401 になる(現状は「トークン未設定のローカル運用」でのみ両立)。

→ 本 issue の inbox ブラウザ認証の設計に含めること。inbox の認証方式(URL トークン / ログイン)を決め、その資格情報を inbox.js の操作 fetch にも載せる。なお inbox は同一オリジンなので CORS の Allow-Headers 拡張はここでは不要(それが必要なのは #44 の cross-origin ingest key 側)。

実装方針の提案: route table + policy を同一スライスで導入

現状ルーティングは手続き的 if 連鎖で、認証適用を各分岐で手で 4 回反復している(server/receive.js:148-231, L178/185/192/199)。本 issue と #44 で認証種別が operation / inbox / ingest の 3 系統に増えるため、適用漏れを防ぐには宣言的なルート表に寄せるのが安全:

{ method, pattern, auth: "none|operation|inbox|ingest", cors: "public|allowlist", handler }

Express 風の汎用 middleware チェーンは現規模には過剰、という判断まで含めて Codex(GPT-5.5)との議論で合意済み。

[kosako]

完了スライスの設計(2026-07-05 壁打ち確定)

inbox ブラウザ認証方式の壁打ちを実施し、以下で確定。

認証方式

1. inbox はログインフォーム + HttpOnly cookie(SameSite=Lax)。URL トークン入口は作らない(receiver を立てない軽量運用は DL/import が代替するため)
2. 資格情報は RECEIVER_TOKEN 1 本を兼用(inbox ログインも操作系 Bearer も同一)。将来の閲覧/操作分離は INBOX_TOKEN 新設 + RECEIVER_TOKEN fallback で後方互換にできるため、今は分けない
3. cookie は HMAC 署名付き派生値(有効期限.HMAC(RECEIVER_TOKEN, 有効期限)、node:crypto のみで zero-dep 維持)。有効期限 7 日。生トークンをブラウザに置かない。トークンローテで全端末即失効
4. 操作系・閲覧系 endpoint とも Bearer OR cookie を受ける → 🔴 F-1(RECEIVER_TOKEN 設定時の inbox 全操作 401)は inbox.js 無改修で解消(HttpOnly cookie は same-origin fetch に自動で乗る)。curl 運用は従来通り Bearer

CORS

5. allowlist 対象は ingest(POST /feedback)のみ。widget は Content-Type: application/json 送信で必ず preflight が飛ぶため、allowlist 外 origin のブラウザ投稿は本体 POST 前に遮断される。inbox・操作系・screenshot は同一オリジン利用のため CORS ヘッダー自体を付けない(認証と二重の防壁)
6. allowedOrigins 未設定 = 従来通り * + 起動ログに警告(RECEIVER_TOKEN と同じ「未設定なら開放」思想でゼロ設定ローカル互換を維持)

付随の決定

7. insert 時に received: { origin, originAllowed } をメタデータ保存(store は JSON round-trip なのでスキーマ変更不要)。inbox での「疑わしい投稿」表示マークは、Origin が偽装可能な弱シグナルしか無い現状では作らず、ingest key という偽装不能なシグナルが手に入る Widget→Receiver 取り込みのペア認証と受信データの安全な取り扱い #44 で設計する
8. 認証有効時、GitHub Issue body の screenshot インライン埋め込み(![...](url))は [Open screenshot] リンクのみに退化(GitHub camo は cookie を送れず埋め込みが壊れるため)。署名付き URL(capability URL)は「URL を知っていれば誰でも見える」への回帰でありスコープ過大のため見送り、必要なら Widget→Receiver 取り込みのペア認証と受信データの安全な取り扱い #44 で再検討

進め方(2 PR)

• PR-1: route table + policy({ method, pattern, auth, cors, handler })導入の純リファクタ。既存 Bearer 認証 4 箇所を宣言に移す。未対応メソッドの 405 + Allow(監査指摘)はルート表から自然に出るためここに含める。挙動同一がレビュー焦点
• PR-2: 挙動変更の本体 — ログインフォーム + HMAC cookie / Bearer OR cookie 受け入れ(F-1 解消)/ CORS 分割 + 未設定警告 / received.origin 保存 / issue body 退化 / inbox レスポンスへの CSP・nosniff / README デプロイ節

スコープ外(明示)

• Content-Type 検証・store の WAL/busy_timeout・外部 URL 検証 → 低優先の細かい修正まとめ（id 衝突 / destroy 後始末 / Slack direct 表示 ほか） #54/receiver 運用ハードニング: graceful shutdown・/healthz・起動時の実効設定サマリ #99 系の別スライス
• ingest key(widget↔receiver ペア認証)→ Widget→Receiver 取り込みのペア認証と受信データの安全な取り扱い #44
• 起動時の実効設定サマリ本体 → receiver 運用ハードニング: graceful shutdown・/healthz・起動時の実効設定サマリ #99

実装時に決める小論点: ログインフォームの体裁 / logout の有無 / cookie Secure 属性の付け方(reverse proxy の HTTPS 判定)。