演習4：公開先の設定を固める

帳簿が正しくても、事務所の鍵が開いていれば意味がありません。アプリの中身が正しくても、公開先の設定が甘ければ同じことです。この章では、Vercel、Supabase、GitHubの設定画面を順に開き、「開いたままになっている鍵」がないかを目視で確かめます。コードは一行も読みません。

アプリの「外側」にある守り

これまでの演習は、アプリの中身（鍵の置き場所、権限の確認、入力の扱い）を見てきました。この章は、アプリを載せている土台の設定です。論文では「セキュリティ設定の不備」が108件（9.11%）で5位でした。OWASP Top 10:2025ではA02に当たります。

典型的な不備は4つです。

• デバッグモードのまま公開。開発中に便利な「詳しいエラーを表示する」設定が、本番でも生きている状態です。
• 管理画面が誰でも開ける。第10章で扱った権限の話に加え、データベースの管理画面やログの画面がインターネットに向いて開いている場合があります。
• CORSが全開。CORS（Cross-Origin Resource Sharing）は、「どのサイトからのブラウザ経由の呼び出しを受け付けるか」の設定です。「すべて許可」にしてあると、他人のサイトに置かれたプログラムから、あなたのAPIをログイン中の利用者の権限で呼べることがあります。AIは動作確認を通すために、これを全開にしがちです。
• エラー画面に内部情報が出る。ファイルの場所、SQLの断片、使っている部品のバージョンが画面に出ると、攻撃する側の下調べを手伝うことになります。

経理で言えば、金庫の鍵を金庫の上に置いているような話です。閉め方は設定画面のスイッチひとつであることがほとんどです。

Vercelで確認すること

• HTTPS。Vercelに載せたアプリは、通信の暗号化（HTTPS）が自動で有効になります。アドレスバーの鍵マークで確認できます。独自ドメインを付けた場合だけ、証明書が発行されているかを一度見ておきます。
• 環境変数。Settings の Environment Variables で、鍵が Production／Preview／Development のどこに設定されているか、Sensitive になっているかを見ます（第9章）。開発用の鍵と本番用の鍵が混ざっていないかも確かめます。
• Deployment Protection。Vercelはコミットのたびにプレビュー用のURLを作ります。このURLを知っている人なら誰でも開ける設定になっていないかを、Deployment Protection の画面で確かめます。Vercel Authentication（Vercelにログインしていて、そのプロジェクトに権限のある人だけが開ける）が有効になっていれば、作りかけの画面が外から見える状態を防げます。
• エラー表示。本番環境で、わざと存在しないURLを開いたり、入力欄に長い文字列を入れたりして（第11章）、エラー画面に内部情報が出ないかを見ます。

Supabaseで確認すること

• RLS。全テーブルで有効か、ポリシーが本人の行だけか（第10章）。
• API Keys。管理用の鍵（secret／service_role）がブラウザ側に出ていないか（第9章）。使っていない旧形式の鍵があれば、無効化を検討します。
• Security Advisor。管理画面の Advisors に出ている警告を、ひとつずつ読みます。「RLSが無効」「ポリシーが無い」「公開スキーマに不要なものがある」といった指摘が、理由つきで並びます。
• Authentication の設定。メールアドレスの確認（確認メールのリンクを踏むまで有効にしない）が有効か。パスワードの最小長が、OWASP ASVS 5.0の目安（最小8文字、15文字以上を強く推奨）に近づいているか。

GitHubで確認すること

• 公開／非公開。リポジトリの Settings の一番上に表示されます。学習用に公開しているなら、第9章の確認（鍵が履歴に無いこと）が済んでいることが前提です。他人のデータを扱うアプリのコードを公開する必要があるかは、一度考え直してください。
• Secret scanning。公開リポジトリでは、GitHubが鍵らしき文字列を自動で検知し、通知します。Settings の Code security で状態を見ます。鍵を含むコミットをそもそも受け付けない「push protection」も、使える場合は有効にします。
• Dependabot alerts。使っている部品（依存パッケージ）に既知の脆弱性が見つかると、GitHubが通知してくれる仕組みです。Settings の Code security で有効になっているか、未対応の通知が溜まっていないかを見ます。
• ブランチ保護。本番に反映されるブランチ（mainなど）へ、確認なしに直接書き込めない設定です。一人で開発しているうちは必須ではありません。同僚と共同で触るなら、「本番への反映には別の人の承認が要る」という統制をここで再現できます。

セキュリティヘッダーと依存パッケージ

この2つは、この章では「存在を知る」ところまでで十分です。

セキュリティヘッダー

サーバーがブラウザに返す応答には、画面の本体のほかに、ブラウザの振る舞いを指示する「ヘッダー」が付いています。そのうちセキュリティに関わるものをセキュリティヘッダーと呼び、たとえば Content-Security-Policy（どこから来たプログラムの実行を許すか）、Strict-Transport-Security（常にHTTPSで接続させる）、X-Content-Type-Options（ファイルの種類の誤解釈を防ぐ）などがあります。OWASPのHTTP Headers Cheat Sheetに一覧があります。どのヘッダーが付いているかは、ブラウザの開発者ツールで自分のアプリの応答を見れば読めます。設定を誤ると画面が表示されなくなるので、中身は必要になったときにAIと相談してください。

依存パッケージの更新

あなたのアプリは、AIに書かせた部分より、他人が作った部品（パッケージ）のほうがはるかに多いのが普通です。部品に脆弱性が見つかれば、あなたのアプリにも穴が開きます。論文でも「サプライチェーンの不備」が73件（6.16%）ありました。Node.jsのプロジェクトなら、npm audit というコマンドで、使っている部品に既知の脆弱性がないかを調べられます。GitHubのDependabotは、同じことを自動で続けてくれます。更新したあとは、動作が変わっていないかを必ず確かめます。

アカウント自体を守る

設定をどれだけ固めても、Vercel・Supabase・GitHubのアカウントそのものが乗っ取られれば、すべてが無に帰します。

• 二要素認証（2FA）。パスワードに加えて、スマートフォンのアプリが出す確認コードなどを求める仕組みです。3つのサービスすべてで有効にします。GitHubは公式ドキュメントで設定手順を公開しています。
• パスワードマネージャー。サービスごとに長い別々のパスワードを生成し、覚える代わりに保管するソフトです。使い回しをやめるための、現実的な唯一の方法です。
• 復旧コードの保管。二要素認証を設定すると、スマートフォンを失ったときのための復旧コードが発行されます。紙に印刷して、鍵のかかる場所に入れておきます。