上級編約35分

上級⑤ セキュリティ総点検

鍵・RLS・ヘッダー・AI監査。公開サービスとしての安全監査を一周する

決済まで備えた今、あなたのサービスは攻撃する価値のある標的になりました。怖がらせたいのではありません——今日の総点検を一周すれば、個人開発として上位の防御水準になります。半年ごとに繰り返せる“監査の型”として身につけましょう。

今日のゴール

5つの観点——鍵・RLS・ヘッダー・認証設定・AI監査——でmy-appを一周点検し、見つかった穴をその場で塞ぐこと。

点検1：鍵の棚卸し——全環境変数を等級分けする

Vercelの環境変数一覧を開いて、1つずつ等級を言えるか確認します。この講座で積み上げてきた集大成です。

環境変数	等級	理由
NEXT_PUBLIC_SUPABASE_URL / ANON_KEY	公開OK	RLSが守る前提の公開用
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY / GA_ID	公開OK	公開前提の識別子
RESEND_API_KEY / ANTHROPIC_API_KEY	サーバー専用	漏れたら他人に使われ課金される
STRIPE_SECRET_KEY / STRIPE_WEBHOOK_SECRET / CRON_SECRET	サーバー専用	決済と内部処理の鍵
SUPABASE_SERVICE_ROLE_KEY	全権（最高機密）	RLSを超える。金庫室（Webhook等）のみ

リポジトリ全体を検索して、APIキーや秘密の値がコードに直書きされていないか、NEXT_PUBLIC_ が付いた秘密の鍵がないか、service_roleキーがブラウザ側のコードからimportされていないかを点検して。問題があれば修正案も。

点検2：RLSの一覧確認＋2アカウントの儀式

SupabaseのSQL Editorで、全テーブルの門番の有無を一覧します。

select tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by tablename;

rowsecurity が false の表がないか——1つでもあれば、その表は丸見えの可能性。即対応。
plan や is_admin のような“権利の列”が、ブラウザから書き換え不可になっているか（上級②の列権限）。
仕上げはいつもの2アカウント確認：別アカウントで他人のデータが見えない・書けないこと。

点検3：セキュリティヘッダー——ブラウザに渡す防御指示

セキュリティヘッダーは、ページを返すときに添える「このサイトはこう守って」というブラウザへの指示書。1ファイルの設定で、いくつもの定番攻撃の芽を摘めます。

next.config に基本のセキュリティヘッダーを設定して：X-Frame-Options（クリックジャッキング対策）、X-Content-Type-Options: nosniff、Referrer-Policy、Permissions-Policy、Strict-Transport-Security。さらに Content-Security-Policy も、SupabaseとStripeとGA4の通信を壊さない形で設定できるか検討して。設定後にログイン・決済・解析が動くことを確認する手順も教えて。まず計画を見せて。

CSPは“最後に・慎重に”

CSP（コンテンツの読み込み元制限）は強力ですが、設定を間違えるとログインや決済が動かなくなります。適用したら必ず：ログイン→保存→決済テスト→解析、を一周確認。壊れたらエラー文をAIへ。

点検4：認証まわりの本番設定

Supabase Authの Confirm email（メール確認）——テスト中にオフにしたままなら、本番はオンに戻す（捨てメールでの大量登録対策）。
パスワードの最低文字数を確認（8文字以上推奨）。
Site URL／Redirect URLs が本番ドメインになっているか。
アカウント削除の導線があるか（ユーザーの“消す権利”。なければ「マイページにアカウント削除機能を付けて。確認ダイアログ付きで」とAIへ）。

点検5：AIに“攻撃者の目”で監査させる

最後に、ここまでの観点をAIの目でまとめて再点検。これを中級①のスキルに足して、いつでも呼べる監査コマンドにしておきましょう。

攻撃者の視点でこのリポジトリを監査して。観点：①秘密の鍵の漏れ・置き場所 ②認可の穴（他人のデータを読める/書ける箇所、planを自分で書き換えられる箇所）③入力検証（長すぎる入力・変な値で壊れる箇所）④XSS（ユーザー入力をそのままHTMLに入れている箇所）⑤決済まわり（金額やプランをブラウザから指定できないか）。重大度順に、修正案つきで報告して。

おさらい：半年ごとの監査チェックリスト

セキュリティ監査・定期チェック（保存版）

0 / 6

上級⑤・完成チェック

0 / 4

お疲れさまでした！

守りはサービスの信用そのもの。この監査を半年ごとに回せば、安心して攻め(機能開発)に集中できます。次回はいよいよ最終回——サービスを成長させる話です。