X-Forwarded-User の信頼境界(なりすまし不可能性)を担保すると決める

背景

認証は NeoShowcase のプロキシが付与する X-Forwarded-User(traQ ID)を信頼する設計(#16)。しかしその「信頼できる」という前提を成立させ・検証する仕組みは未決。

なぜ今決めるか

コンテナのポートがプロキシを経由せず直接到達可能だと、あるいはプロキシがクライアント由来の X-Forwarded-User を除去しなければ、任意の攻撃者がヘッダを偽装して任意のユーザーになりすませる。これは全認可の土台で、後から塞ぐのは高い。#16 は「信頼済みプロキシ前提」と仮定するだけで、その仮定を担保する担当がいない。

論点・選択肢

• ネットワーク的に Nitro を直接到達不能にする(NeoShowcase の設定で外部/内部からの直接アクセスを遮断)。
• アプリ側でクライアント由来のヘッダを常に無視・上書きし、プロキシが付与した値のみ採用する。
• プロキシ↔アプリ間の共有シークレットで経路を検証する。
• これらを多重防御として併用するか。

受け入れ条件

• X-Forwarded-User を信頼できる条件(なりすまし不可能性)が、コードと配備の両面で決まっている。
• #16 のプリンシパル注入(apps/web/server/routes/rpc/[...].ts)がこの境界の上に載る前提で設計されている。

関連

#16(認証サブシステム)の前提(子)。#15(認可)の土台。

Read apps/web/server/routes/rpc/[...].ts and the context in issues #16 and #15 first. Determine and document the code- and deployment-level conditions that make X-Forwarded-User trustworthy, then confirm the principal injection and deployment plan satisfy the acceptance criteria.