認証付き社内Webアプリの一部だけを社外へ匿名公開する（前段ゲートウェイがある構成の落とし穴）

社内向けに作った認証必須の Web アプリの中に、社外の人へ渡したい画面が1つだけ出てくることがある（空き日程の案内、受付フォーム、ステータス確認など）。 このとき「本体アプリに認証不要のルートを1本足す」だけでは外部から動かない構成がある。前段にゲートウェイ（リバースプロキシ役のアプリ）が挟まっている場合で、しかもローカル検証では成功してしまうため気づきにくい。

対象読者: 自宅／社内PCのアプリをトンネル（Tailscale Funnel、Cloudflare Tunnel、ngrok 等）で公開している人。

---

1. まず構成を実測する。README を信じない

公開URLが本体アプリに直結しているとは限らない。必ずトンネルの転送先を実測してから設計する。

# Tailscale Funnel の場合
tailscale serve status

https://<公開ホスト> (Funnel on)
|-- / proxy http://localhost:3939      # ← 本体が 3940 でも、ここが 3939 のことがある

この例では 3939 に別のゲートウェイアプリがいて、そこから本体（3940）へ中継している。 リポジトリの README に「トンネルは本体ポートに向く」と書かれていても、運用の途中でゲートウェイが挟まって README だけ古いままというのはよくある。実測値を正とする。

ゲートウェイの典型的な作り（Next.js の例）:

• 非 API パスは rewrite で本体へ素通し
• API パスだけは自前のハンドラを通し、そこで認証してから本体へ中継する（本体のトークンをサーバ側で付け直す）

// 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条件で絞る。パスだけで開けると、同じ接頭辞下の書き込みまで公開される。

// gateway/app/<本体basePath>/api/[...path]/route.ts
async function proxyRequest(req: NextRequest, context: { params: { path: string[] } }) {
  // /<basePath>/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 件など。完全でなくてよい）

return Response.json({
  items: publicItems,        // 必要最小限のフィールドだけ詰め替えたもの
  text: formatForHumans(),   // そのままコピーして相手に貼れる整形済みテキスト
  generatedAt: nowIso(),
  freshness: isStale ? 'stale' : 'ok',
});

社外の人がそのまま相手に貼れる text を一緒に返すと、受け取った側の手間が減る。

---

5. 検証は必ず公開URLに対して行う

localhost の 200 を本番の証拠にしない。 最低限これだけは公開URLに対して自動で確かめる。

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つ挟むだけでも、無差別のアクセスは実用上ほぼ止まる（強度は求めない、誤爆防止の意味）。