# 認証付き社内Webアプリの一部だけを社外へ匿名公開する（前段ゲートウェイがある構成の落とし穴） 社内向けに作った認証必須の Web アプリの中に、社外の人へ渡したい画面が1つだけ出てくることがある（空き日程の案内、受付フォーム、ステータス確認など）。 このとき「本体アプリに認証不要のルートを1本足す」だけでは**外部から動かない構成がある**。前段にゲートウェイ（リバースプロキシ役のアプリ）が挟まっている場合で、しかも**ローカル検証では成功してしまう**ため気づきにくい。 対象読者: 自宅／社内PCのアプリをトンネル（Tailscale Funnel、Cloudflare Tunnel、ngrok 等）で公開している人。 --- ## 1. まず構成を実測する。README を信じない 公開URLが本体アプリに直結しているとは限らない。**必ずトンネルの転送先を実測してから設計する。** ```bash # Tailscale Funnel の場合 tailscale serve status ``` ``` https://<公開ホスト> (Funnel on) |-- / proxy http://localhost:3939 # ← 本体が 3940 でも、ここが 3939 のことがある ``` この例では 3939 に**別のゲートウェイアプリ**がいて、そこから本体（3940）へ中継している。 リポジトリの README に「トンネルは本体ポートに向く」と書かれていても、**運用の途中でゲートウェイが挟まって README だけ古いまま**というのはよくある。実測値を正とする。 ゲートウェイの典型的な作り（Next.js の例）: - 非 API パスは rewrite で本体へ素通し - **API パスだけ**は自前のハンドラを通し、そこで認証してから本体へ中継する（本体のトークンをサーバ側で付け直す） ```js // gateway/next.config.js async rewrites() { return [ { source: '/app', destination: 'http://localhost:3940/app' }, // api 以外は本体へ直接。api は下のハンドラに落とす { source: '/app/:path((?!api(?:/|$)).*)', destination: 'http://localhost:3940/app/:path*' }, ]; } ``` --- ## 2. 落とし穴: 本体だけ直しても外部からは 401 本体アプリに認証不要のルート `/app/api/public/...` を新設しても、ゲートウェイの中継ハンドラが `/app/api/*` を**無条件に認証**していると、外部URLでは 401 になる。 **なぜ気づきにくいか** | 叩き先 | 結果 | |---|---| | `http://localhost:<本体ポート>/app/api/public/...` | **200**（ゲートウェイを経由しないため） | | `https://<公開ホスト>/app/api/public/...` | **401**（ゲートウェイで止まる） | 公開**ページ**自体は rewrite で素通しなので 200 で開ける。だから「ページは表示される、でも中身が出ない」という壊れ方をする。 ローカル検証だけで「本番OK」と判断すると確実に見落とす。AI コーディングエージェントに任せた場合も、localhost の 200 を根拠に完了報告してくることがある。 --- ## 3. 直し方: ゲートウェイ側に「公開パスの素通し」を1箇所だけ書く 素通しは**パス接頭辞 + 読み取りメソッド**の2条件で絞る。パスだけで開けると、同じ接頭辞下の書き込みまで公開される。 ```ts // gateway/app/<本体basePath>/api/[...path]/route.ts async function proxyRequest(req: NextRequest, context: { params: { path: string[] } }) { // //api/public/* は社外向けの公開エンドポイント。 // ゲートウェイの認証は通さず読み取りだけ素通しする。書き込みは従来どおり認証必須。 const isPublicRead = context.params.path[0] === 'public' && (req.method === 'GET' || req.method === 'HEAD'); if (!isPublicRead) { const auth = checkAuth(req); if (!auth.ok) return NextResponse.json({ error: auth.message }, { status: auth.status }); } // 以降は従来どおり本体へ中継（本体用トークンをサーバ側で付け直す） } ``` 修正後は**ゲートウェイを再ビルドして再起動する**こと（ポートは変えない、本体プロセスは止めない）。ここを忘れると直したのに 401 のままになる。 --- ## 4. 公開APIが返してよいものを先に決める 「認証を外す」と「情報を出す」は別の判断。公開エンドポイントは**ホワイトリストで組み立てる**（内部の型をそのまま返さない）。 - 返す: 求められた答えそのものだけ（例: 日付と時間帯） - 返さない: 予定や案件のタイトル、顧客名・個人名、場所、会議URL、件数、内部ID、キャッシュの更新時刻やファイルパス、エラーの内部事情 - **「該当なし」の理由も返さない**。理由を返すと外から内部状態を推測できる。該当しない行はレスポンスから落とす - エラー本文は利用者向けの固定文言にし、サーバのエラー文字列を画面に出さない - 簡易レート制限を入れる（プロセス内 Map で IP ごと60秒 N 件など。完全でなくてよい） ```ts return Response.json({ items: publicItems, // 必要最小限のフィールドだけ詰め替えたもの text: formatForHumans(), // そのままコピーして相手に貼れる整形済みテキスト generatedAt: nowIso(), freshness: isStale ? 'stale' : 'ok', }); ``` 社外の人がそのまま相手に貼れる `text` を一緒に返すと、受け取った側の手間が減る。 --- ## 5. 検証は必ず公開URLに対して行う **localhost の 200 を本番の証拠にしない。** 最低限これだけは公開URLに対して自動で確かめる。 ```js const BASE = 'https://<公開ホスト>'; const FORBIDDEN = ['summary', 'location', 'customerName', 'eventsCount']; // 出てはいけないキー // 1. 公開API: Cookie も Authorization も付けずに 200、かつ機微キーが出ない // 2. 既存の認証API: 認証なしで 401（公開化が波及していない） // 3. 公開APIへの POST: 401 か 405（書き込みを素通ししていない） // 4. 公開ページ: 200 で、想定の見出し文字列を含む // 5. 既存トップ: 200（他の画面を壊していない） ``` `fetch(url, { redirect: 'manual' })` で叩き、レスポンス本文に `"<禁止キー>"` が含まれないことを機械的に判定する。目視確認にしない。 2 と 3 を省くと、「公開したつもりが全体を開けてしまった」事故に気づけない。 --- ## 6. チェックリスト - [ ] トンネルの転送先を実測した（README ではなく `serve status` 等の出力で） - [ ] 前段ゲートウェイの有無を確認した - [ ] ゲートウェイ側に公開パスの素通しを書いた（接頭辞 + GET/HEAD のみ） - [ ] ゲートウェイを再ビルド・再起動した - [ ] 公開APIの返却フィールドをホワイトリストで組んだ - [ ] 「該当なし」の理由を返していない - [ ] レート制限を入れた - [ ] 公開URLに対して 5 節の 1〜5 を全部 PASS させた - [ ] 公開URLを知っていれば誰でも見られることを、依頼者に明示して合意した - [ ] README に「トンネル→ゲートウェイ→本体」の実際の経路とポートを書いた --- ## 補足: そもそも公開してよいか URL を知っていれば誰でも開ける＝リンクが外部に転送されれば第三者も見られる、ということ。 「社外の人に渡したい」と「インターネットに公開してよい」は別なので、依頼者に**何が出るか**を具体的に示して合意を取ってから公開する。 合言葉を1つ挟むだけでも、無差別のアクセスは実用上ほぼ止まる（強度は求めない、誤爆防止の意味）。 ---