nextjs/saas-starter

inviteTeamMember (lines 399-459) loads the caller's team via getUserWithTeam and immediately inserts an invitation with the caller-chosen role ('member' | 'owner'). There is no check of teamMembers.role or users.role. The only gate is the disabled attribute on the form in app/(dashboard)/dashboard/page.tsx lines 215/224/245, which is client-side and trivially bypassed by calling the action directly. Also the UI uses user.role from the users table, which signUp always sets to 'owner' (see F9), so the check would be wrong even if it were enforced.

Any team member can invite an arbitrary email as an owner, escalating themselves (via a second account) or an accomplice to owner and then removing the real owners or managing billing.

Look up the caller's row in teamMembers for this team and require role === 'owner' before inserting. Example: const me = await db.query.teamMembers.findFirst({ where: and(eq(teamMembers.userId, user.id), eq(teamMembers.teamId, userWithTeam.teamId)) }); if (me?.role !== 'owner') return { error: 'Only team owners can invite members' };

In app/(login)/actions.ts, inside the inviteTeamMember server action (after the `if (!userWithTeam?.teamId)` check), query team_members for the row where userId = user.id and teamId = userWithTeam.teamId and return { error: 'Only team owners can invite members' } unless that row's role is 'owner'. Do the same check in removeTeamMember. Reason: authorization is currently only enforced by disabled form inputs in the client; the server action accepts any authenticated team member and any role value.

removeTeamMemberSchema declares memberId: z.number(). validatedActionWithUser (lib/auth/middleware.ts line 47) parses Object.fromEntries(formData), where every value is a string. z.number() rejects '3', so the action returns { error: 'Expected number, received string' } on every submit and the delete on line 375 is never reached.

The Remove button on the team page never works. Owners cannot remove members after launch; the error message shown is a raw zod message.

Use coercion: memberId: z.coerce.number().int().positive(). Then also add the owner check from F1 and prevent removing the last owner.

In app/(login)/actions.ts change removeTeamMemberSchema from `memberId: z.number()` to `memberId: z.coerce.number().int().positive()`. Reason: server actions receive FormData whose values are always strings, so z.number() rejects every submission and the Remove Member button is non-functional.

Once F2 is fixed, removeTeamMember deletes any teamMembers row matching (memberId, caller's teamId) with no check that the caller is an owner, no protection against removing the last owner, and no check against removing yourself. The UI hides the button for index <= 1 (dashboard/page.tsx line 156), which is unrelated to role and is client-only.

A regular member can kick every owner out of the team and take control of a team that has an active paid subscription.

Require caller role 'owner' (see F1); refuse to remove a member whose role is 'owner' if they are the last owner; refuse memberId that maps to the caller unless another owner exists. Wrap in a transaction.

In app/(login)/actions.ts removeTeamMember: before the delete, (1) load the caller's team_members row and return an error unless role === 'owner'; (2) load the target row by id+teamId and, if target.role === 'owner', count remaining owners in the team and refuse if it would leave zero; (3) run the checks and delete in a db.transaction. Reason: the action currently trusts any authenticated team member to delete any membership row in the team.

getUser() (lib/db/queries.ts line 26) does db.select() with no column list, returning passwordHash, role, deletedAt, etc. app/api/user/route.ts returns it via Response.json(user), and app/layout.tsx line 34 passes getUser() into the SWRConfig fallback, so the hash is also serialized into the HTML/RSC payload of every page. /api/team similarly ships stripeCustomerId and stripeSubscriptionId to every member.

Every logged-in page load leaks the user's bcrypt hash to the client, browser extensions, and any XSS. Offline cracking of weak passwords becomes possible from a single captured response; Stripe IDs leak to non-owner members.

Select only safe columns in getUser (or strip before returning): const { passwordHash, ...safeUser } = user; Return safeUser from /api/user and the layout fallback. For /api/team, omit stripe* columns for the client-facing shape.

In lib/db/queries.ts, change getUser() to select explicit columns { id, name, email, role, createdAt, updatedAt } from users (never password_hash), and create a separate getUserWithPasswordHash() for the auth code paths in app/(login)/actions.ts and lib/auth/middleware.ts that need to call comparePasswords. Update app/api/user/route.ts and app/layout.tsx to use the safe version. In getTeamForUser, exclude stripeCustomerId and stripeSubscriptionId from the returned team columns. Reason: the full users row including the bcrypt hash is currently JSON-serialized to the browser on every page.

signUp accepts inviteId from a hidden form field and matches invitations where id = parseInt(inviteId), email = the email the attacker typed, and status = 'pending'. Email addresses are never verified anywhere in the app, and invitation ids are a serial integer. An attacker who knows or guesses that alice@corp.com was invited can sign up as alice@corp.com with inviteId 1..N and join the team with whatever role was granted (possibly 'owner'). Invitations also never expire and no email is actually sent (TODO on line 454), so the legitimate flow does not work at all.

Pending invitations are claimable by anyone who can guess an email; combined with F1 this allows owner-level takeover of a paying team. Meanwhile real invitees never receive a link.

Add a random token column (crypto.randomBytes(32).toString('hex')) and expiresAt to invitations; look invitations up by token instead of id; send the token by email; mark accepted inside the same transaction as team_members insert. Add email verification (or at least require the invite token to prove control of the inbox).

In lib/db/schema.ts add `token: text('token').notNull().unique()` and `expiresAt: timestamp('expires_at').notNull()` to the invitations table and generate a migration. In app/(login)/actions.ts inviteTeamMember, generate token with crypto.randomBytes(32).toString('hex') and expiresAt = now + 7 days; in signUp, replace the lookup by parseInt(inviteId) with a lookup by token (rename the hidden field to inviteToken in app/(login)/login.tsx) and also require expiresAt > now. Wire an email send with the link /sign-up?inviteToken=... Reason: invitation ids are guessable serial integers and emails are unverified, so pending invites can be hijacked.

The route is unauthenticated (middleware excludes /api). It reads client_reference_id from the Stripe session, loads that user, writes subscription data to the user's team, and calls setSession(user[0]) — issuing a fresh session cookie for that user to whoever made the request. It never checks that the request comes from the same logged-in user, nor that session.status === 'complete' / payment_status. Checkout session ids appear in the Stripe-hosted checkout URL, browser history, referrers and logs.

Anyone who obtains a cs_... id (shared link, shoulder-surfed URL, log access) can log in as that customer indefinitely (the sliding session never expires, see F13). A stale or incomplete session could also be replayed to (re)write team billing state.

Do not call setSession here; require the current session user (getUser()) to equal client_reference_id, or simply skip the login and only update the team. Verify session.status === 'complete' before writing. Prefer making the webhook (checkout.session.completed) the source of truth and let this route only redirect.

In app/api/stripe/checkout/route.ts: (1) remove the `await setSession(user[0])` call; (2) after retrieving the session, `if (session.status !== 'complete') throw new Error('Checkout not complete')`; (3) call getUser() from lib/db/queries and, if a user is logged in, require String(user.id) === session.client_reference_id, otherwise redirect to /sign-in. Reason: the route currently mints a session cookie for the user referenced by any checkout session id presented to it, turning a leaked URL into an account login.

teams.stripeCustomerId is only written in the success redirect route (app/api/stripe/checkout/route.ts line 82). The webhook (app/api/stripe/webhook/route.ts lines 24-25) handles only customer.subscription.updated/deleted and handleSubscriptionChange looks the team up by stripeCustomerId (line 124). For a first-time subscriber, the customer is created by Stripe during checkout, so if the user closes the tab, loses connectivity, or the redirect route throws (e.g. product not expanded), stripeCustomerId is never set and every later webhook logs 'Team not found' and returns. checkout.session.completed and customer.subscription.created are unhandled.

Customers are charged (after trial) with no subscription reflected in the app and no way for the webhook to ever reconcile. Support tickets and refunds.

Handle checkout.session.completed in the webhook: read session.client_reference_id (or put teamId in session.metadata), retrieve the subscription, and upsert stripeCustomerId/subscription fields on the team. Make the redirect route idempotent and purely cosmetic. Also handle customer.subscription.created.

In lib/payments/stripe.ts createCheckoutSession, add `metadata: { teamId: String(team.id) }` to the checkout session. In app/api/stripe/webhook/route.ts add a case for 'checkout.session.completed' that reads event.data.object.metadata.teamId, retrieves the subscription with items.data.price.product expanded, and calls updateTeamSubscription with stripeCustomerId, stripeSubscriptionId, stripeProductId, planName and status (extend updateTeamSubscription in lib/db/queries.ts to accept stripeCustomerId). Also add 'customer.subscription.created' to the existing handleSubscriptionChange case. Reason: today the DB is only updated by the success-page redirect, so a closed tab means a paying customer with no plan and webhooks can't find the team.