[DeepSec] メール所有確認なしの公開ユーザー登録で業務データへアクセスできる

[TkymHrt]

概要

DeepSec の診断で、公開されているユーザー登録フローがメール所有確認や招待・承認なしにアプリケーション利用者を作成し、認証済みユーザー向けのタスクデータへアクセスできる可能性が検出されました。

この Issue は同一根本原因の以下 4 件をまとめています。

• src/app/(auth)/register/page.tsx
• src/features/auth/server/actions.ts
• src/features/auth/ui/sign-up-form.tsx
• src/lib/supabase/proxy.ts

影響

/register が公開パスとして扱われ、SignUpForm から registerAction を呼び出せます。registerAction はメールアドレスの形式チェックのみで supabase.auth.signUp を実行し、Supabase が即時 session を返す場合は / へ遷移します。

診断結果では、メール確認が無効化されており、auth user trigger により public.users に通常ユーザー相当のレコードが作成される構成が指摘されています。そのため、攻撃者が所有していない NUTFes 風の Gmail アドレス文字列を使って登録し、通常ユーザーが閲覧できる task / item / location などの業務データへアクセスできる可能性があります。

対象

• src/app/(auth)/register/page.tsx: line 4
• src/features/auth/server/actions.ts: lines 56, 74, 90, 93, 97
• src/features/auth/ui/sign-up-form.tsx: lines 32, 51
• src/lib/supabase/proxy.ts: lines 47, 48
• DeepSec severity: MEDIUM
• Confidence: high / medium
• Slug: auth-bypass, other-unverified-self-registration, public-endpoint

修正案

• メール確認を有効化し、所有確認が完了するまでアプリケーション session として扱わない
• 公開 signup を無効化し、招待制または管理者承認制にする
• 新規作成された profile を pending / no-access 状態で作成し、承認前は requireAuthenticatedUser や RLS で業務データを読ませない
• メール形式の正規表現だけで所属確認を完了した扱いにしない

受け入れ条件

• 未確認・未承認ユーザーが /tasks などの認証済み業務データへアクセスできない
• 登録直後の session が返る設定でも、アプリケーション側で verified / approved 状態を確認する
• RLS またはサーバー側認可で pending ユーザーの読み取りが拒否される