makerkit/nextjs-saas-starter-kit-lite

`exchangeCodeForSession` reads `searchParams.get('next')` and, when there is no `code` and no `error`, returns it unchanged as `nextPath` (line 181). `apps/web/app/auth/callback/route.ts` line 16 then calls `redirect(nextPath)`. Next.js `redirect()` accepts absolute URLs, so `GET /auth/callback?next=https://evil.example` on your domain 307s to the attacker's site with no auth step in between. The proxy only bounces logged-in users away from `/auth/*`, so any logged-out visitor is exposed. The same pattern exists in `apps/web/app/update-password/page.tsx` line 47, where the `callback` search param becomes `redirectTo` for the update-password form.

Phishing links that start on your trusted domain and land on an attacker page (classic credential-harvest flow: 'your session expired, sign in again'). Also breaks OAuth allow-listing assumptions since the app itself becomes the redirector.

Only accept same-origin relative paths. Add a helper and use it for `next` in both `exchangeCodeForSession` and `verifyTokenHash`, and for `callback` in update-password: function safePath(value: string | null, fallback: string) { if (!value) return fallback; if (!value.startsWith('/') || value.startsWith('//') || value.startsWith('/\\')) return fallback; return value; } const nextUrl = safePath(nextUrlPathFromParams, params.redirectPath);

In packages/supabase/src/auth-callback.service.ts, the `next` query parameter is used as a redirect target without validation (line 136-139 in exchangeCodeForSession, and the `callbackNextPath` value in verifyTokenHash around line 66-73). Add a module-level helper `safeRelativePath(value: string | null, fallback: string): string` that returns `fallback` unless `value` starts with a single '/' and does not start with '//' or '/\\'. Use it so `nextUrl` in exchangeCodeForSession and `nextPath` in verifyTokenHash can never be an absolute or protocol-relative URL. Then in apps/web/app/update-password/page.tsx, apply the same validation to the `callback` search param before passing it as `redirectTo` to UpdatePasswordForm (fall back to pathsConfig.app.home). Reason: `redirect()` accepts absolute URLs, so `/auth/callback?next=https://evil.example` is currently an open redirect.

`accounts.id` is `uuid unique not null default uuid_generate_v4()` with no `references auth.users(id) on delete cascade`. `kit.new_user_created_setup` inserts a row with `id = new.id` and `email = new.email` (line 253-260), and `email` is `unique` (line 94). `deletePersonalAccountAction` deletes only the auth user via `adminClient.auth.admin.deleteUser(userId)`. The `accounts` row (and the user's public avatar object in the `account_image` bucket) survive. When that person signs up again with the same email, the trigger's insert violates the email unique constraint, the trigger raises, and Supabase user creation fails.

Anyone who deletes their account can never register again with that email (sign-up returns a database error). Personal data (name, email, avatar) persists after the user asked for deletion, which is a GDPR problem. Orphan rows accumulate with no owner.

Add a migration: alter table public.accounts add constraint accounts_id_fkey foreign key (id) references auth.users(id) on delete cascade; (Clean up existing orphans first: `delete from public.accounts a where not exists (select 1 from auth.users u where u.id = a.id);`.) In DeletePersonalAccountService also remove the avatar: `await adminClient.storage.from('account_image').remove([...])` for objects whose filename is `${userId}.*` (list the bucket with a `search: userId` filter first).

Create a new Supabase migration in apps/web/supabase/migrations/ that (1) deletes orphaned rows: `delete from public.accounts a where not exists (select 1 from auth.users u where u.id = a.id);` and (2) adds `alter table public.accounts add constraint accounts_id_fkey foreign key (id) references auth.users(id) on delete cascade;`. Then in packages/features/accounts/src/server/services/delete-personal-account.service.ts, before calling `adminClient.auth.admin.deleteUser(userId)`, list objects in the `account_image` bucket matching the user id (`adminClient.storage.from('account_image').list('', { search: userId })`) and remove them with `.remove(paths)`. Reason: accounts.id currently has no FK to auth.users, so deleting the auth user leaves an orphaned accounts row whose unique email prevents the same email from ever signing up again, and the public avatar stays online.

supabase-js admin methods do not throw; they resolve to `{ data, error }`. Line 49 awaits `deleteUser(userId)` and discards the result, so the try/catch on lines 48-60 only catches network-level exceptions. Any Supabase-side failure (invalid service role key, project paused, 4xx/5xx from GoTrue) is swallowed; the code then logs 'User successfully deleted!', the action calls `revalidatePath` and redirects to `/`. Note also that `server-actions.ts` line 57 signs the user out globally *before* attempting the delete, so on failure the user is logged out of every device but the account still exists.

Users see 'account deleted' when nothing happened. Their data stays, they can log back in, and you have a false audit log entry saying the deletion succeeded.

const { error } = await params.adminClient.auth.admin.deleteUser(userId); if (error) { logger.error({ ...ctx, error }, 'Encountered an error deleting user'); throw new Error('Error deleting user'); } And in server-actions.ts, move `client.auth.signOut()` to after `deletePersonalAccount` resolves (or drop it: deleting the user invalidates the session anyway).

In packages/features/accounts/src/server/services/delete-personal-account.service.ts, change line 49 to destructure the result: `const { error } = await params.adminClient.auth.admin.deleteUser(userId);` and if `error` is truthy, log it with logger.error and `throw new Error('Error deleting user')`. Keep the existing try/catch for thrown exceptions. Then in packages/features/accounts/src/server/server-actions.ts, move the `await client.auth.signOut();` call (line 57) to after `service.deletePersonalAccount(...)` completes successfully. Reason: supabase-js admin methods return `{ data, error }` instead of throwing, so failed deletions are currently reported as success, and signing out before the delete leaves users locked out of an account that still exists when the delete fails.