RLSが有効でも、メール一致だけの更新を止めた話

今日は、Next.jsとSupabaseで運営している美容系マッチングサービスのセキュリティを見直した。

最初に確認したのは、データベースのRLS、管理APIの認証、Storage設定、依存パッケージだった。公開テーブル51件はすべてRLSが有効で、未ログイン状態から管理APIを呼ぶと401になる。ここだけを見ると「問題なし」と言いたくなる。

ただ、登録処理をコードまで追うと別の課題が見つかった。登録フォームから同じメールアドレスが送られた場合、それを本人からの再送とみなし、既存情報を更新できる流れが残っていた。RLSが有効でも、アプリ側が管理権限で正規の更新として処理すれば防げない。データベースの権限と、操作している人の本人確認は別の境界だった。

そこで、新規登録と既存情報の編集を分けた。同じメールアドレスで再送されても既存データは変更せず、編集は本人専用ページまたはログイン後だけに限定する方針へ変更した。ネイル、まつエク、エステの3つの登録入口も同じ基準で確認した。

修正後は、通常の登録だけでなく、重複登録、並列送信、DB関数の直接呼び出し、2段階認証の前後で権限が変わらないかをテストした。追加分を含む111件は通過したが、本番反映は急がず、Preview環境へ本番用の管理キーや送信キーを渡さない設定も分けて確認している。

今回改めて感じたのは、RLSや認証を入れただけでは安全確認は終わらないということだった。「誰が読めるか」だけでなく、「誰の操作として更新されるか」まで追う必要がある。

Next.js・Supabaseで作られた既存サイトのセキュリティ確認や、小規模な認証・権限改修からご相談いただけます。現在の構成を確認し、影響範囲と検証項目を整理してから安全に進めます。