Demo invoicing app

Supabase tables public.invoices and public.customers. Row-level security is on. The policies do not look at the organization:

create policy "Authenticated users can read invoices"
on public.invoices for select
to authenticated
using (true);

create policy "Authenticated users can update invoices"
on public.invoices for update
to authenticated
using (true);

customers has the same pair.

Sign up for a free account, then ask the database directly for all rows. They get every organization's invoices and customer contact details. They can also change amounts or mark invoices as paid. The app's own screens filter by organization, so you never see this by clicking around.

1. Sign in as user B (Org B). Copy the access token from the session.
2. Run:

   curl "$SUPABASE_URL/rest/v1/invoices?select=id,org_id,total" \
     -H "apikey: $ANON_KEY" \
     -H "Authorization: Bearer $USER_B_TOKEN"

3. The response includes Org A's invoices.
4. Send a PATCH to /rest/v1/invoices?id=eq.1042 (an Org A invoice) with the body {"status":"paid"}. It returns 204 and the row changes.

Replace the policies so each one checks membership. Do the same for customers, and for insert and delete.

drop policy "Authenticated users can read invoices" on public.invoices;
drop policy "Authenticated users can update invoices" on public.invoices;

create policy "Members read their org's invoices"
on public.invoices for select
to authenticated
using (
  org_id in (
    select org_id from public.org_members
    where user_id = (select auth.uid())
  )
);

create policy "Members update their org's invoices"
on public.invoices for update
to authenticated
using (
  org_id in (
    select org_id from public.org_members
    where user_id = (select auth.uid())
  )
)
with check (
  org_id in (
    select org_id from public.org_members
    where user_id = (select auth.uid())
  )
);

The with check part stops a user moving a row into another organization. This relies on org_members letting a user read their own membership rows. It does. I checked that policy and it is correct.

Yes. It only shows when at least two organizations have data. With one test account everything looks fine, which is why this is easy to miss.

app/api/stripe/webhook/route.ts. The handler reads the body with await req.json() and acts on it. It never checks the stripe-signature header.

Send a made-up "checkout completed" message to the webhook address and get the Pro plan without paying. The address is easy to guess. They only need their own organization id, which the app shows them.

1. Confirm Org B is on the Free plan.
2. Run, with Org B's id filled in:

   curl -X POST "$STAGING_URL/api/stripe/webhook" \
     -H "Content-Type: application/json" \
     -d '{"id":"evt_fake_1","type":"checkout.session.completed","data":{"object":{"client_reference_id":"ORG_B_ID"}}}'

3. The response is 200. Reload the billing page as user B. Org B is on Pro.

Read the raw body and let the Stripe library verify it before doing anything else.

import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
  const body = await req.text();
  const signature = req.headers.get('stripe-signature');
  if (!signature) {
    return new Response('Missing signature', { status: 400 });
  }

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!
    );
  } catch {
    return new Response('Invalid signature', { status: 400 });
  }

  // handle event.type here
  return new Response(null, { status: 200 });
}

Use req.text(), not req.json(). The check needs the exact bytes Stripe sent. STRIPE_WEBHOOK_SECRET is the signing secret of the webhook endpoint in the Stripe dashboard. Staging and production each have their own.

No. It works against any organization at any time.

app/api/invoices/[id]/pdf/route.ts. The route checks that someone is signed in, then loads the invoice with the service role client. That client skips row-level security, and the route does not check the organization itself. Invoice ids are sequential numbers.

Any signed-in user can download any invoice as a PDF by changing the number in the address. They can walk through the numbers and collect all of them.

1. Sign in as user B in the browser.
2. Open $STAGING_URL/api/invoices/1042/pdf. Invoice 1042 belongs to Org A.
3. The PDF downloads.

Load the invoice with the signed-in user's client, so row-level security decides. Return 404 when nothing comes back.

import { createClient } from '@/lib/supabase/server'; // cookie-based client, not the service role one

export async function GET(
  _req: Request,
  { params }: { params: Promise<{ id: string }> }
) {
  const { id } = await params;
  const supabase = await createClient();

  const { data: invoice } = await supabase
    .from('invoices')
    .select('*')
    .eq('id', id)
    .maybeSingle();

  if (!invoice) {
    return new Response('Not found', { status: 404 });
  }

  // build and return the PDF
}

This fix only works after F-01 is fixed. Until then the user's client can read everything too. The CSV export route already uses the user's client, so it becomes safe with F-01.

Slightly. The number must be an existing invoice. Because the numbers are sequential, any number below the newest one works.

The file .env.local was committed in the first week of the project and deleted from the repo later. Deleting a file does not remove it from history. The old commits still hold SUPABASE_SERVICE_ROLE_KEY and STRIPE_SECRET_KEY (a test-mode key).

The service role key skips every access rule in the database. Anyone who gets a copy of the repo can read, change or delete all data. That includes a contractor, a tool you connect to the repo, or anyone at all if the repo is ever made public. The repo is private today, which is why this is high and not critical.

1. In a clone of the repo, run:

   git log --all --oneline -- .env.local

2. Take the oldest commit id from the list and run:

   git show COMMIT_ID:.env.local

3. The keys are printed. The owner confirmed that the staging key has not been changed since, and that production was set up the same way.

1. Create new keys in the Supabase project settings, for staging and for production. Put the new values in the hosting environment variables and redeploy.
2. Be aware: if the project uses the older JWT-based keys, changing them also changes the anon key and signs every user out. Do it before launch, not after.
3. Roll the Stripe test key as well.
4. Make sure the file cannot come back:

   echo ".env*.local" >> .gitignore
   git rm --cached .env.local --ignore-unmatch

Once the keys are changed, the old ones in history are useless. You do not need to rewrite history.

No.

app/api/invoices/recurring/route.ts and app/api/invoices/export/route.ts. The buttons for recurring invoices and CSV export are hidden for Free organizations in components/InvoiceToolbar.tsx. Neither route checks the plan.

A Free user who calls the routes directly gets both Pro features. No one else's data is exposed. You lose the upgrade.

1. Sign in as user B (Free plan). In the browser's developer tools, open the console.
2. Run:

   await fetch('/api/invoices/recurring', {
     method: 'POST',
     headers: { 'Content-Type': 'application/json' },
     body: JSON.stringify({ customerId: 7, interval: 'month', total: 100 }),
   }).then((r) => r.status);

3. It returns 201 and a recurring invoice appears for Org B. Customer 7 is one of Org B's own customers.

Check the plan at the top of each Pro route. Take the organization from the signed-in user's membership, never from the request body.

const { data: org } = await supabase
  .from('organizations')
  .select('plan')
  .eq('id', orgId)
  .single();

if (org?.plan !== 'pro') {
  return Response.json({ error: 'Pro plan required' }, { status: 403 });
}

Put this in one helper and call it from both routes, so the next Pro feature does not forget it.

Yes. You need an account on the Free plan to see it. An owner testing with their own Pro account never will.

Supabase Storage bucket attachments. The bucket is public. Files are stored at ORG_ID/FILE_ID.pdf, where both ids are random. The app shows the public URL.

The paths cannot be guessed, so a stranger cannot browse the files. But anyone who has a link can open the file without signing in, forever. That covers a forwarded email, a link pasted in a chat, and a team member who has been removed from the organization.

1. As user A, upload an attachment to an invoice and copy its link. It looks like $SUPABASE_URL/storage/v1/object/public/attachments/ORG_A_ID/FILE_ID.pdf.
2. Open the link in a private window with no one signed in.
3. The file downloads.

Make the bucket private, add a policy, and hand out short-lived links.

update storage.buckets set public = false where id = 'attachments';

create policy "Members read their org's attachments"
on storage.objects for select
to authenticated
using (
  bucket_id = 'attachments'
  and (storage.foldername(name))[1] in (
    select org_id::text from public.org_members
    where user_id = (select auth.uid())
  )
);

const { data, error } = await supabase.storage
  .from('attachments')
  .createSignedUrl(path, 60); // valid for 60 seconds

// send the user to data.signedUrl

Add matching insert and delete policies. The old public links stop working as soon as the bucket is private.

Yes. Someone must already hold a link.

app/auth/callback/route.ts. The route reads the next value from the address and redirects to it without checking it.

Send your user a link that starts on your real domain. The user signs in on your real page and then lands on the sender's site, which can be a copy of yours asking for a password or card details. No data leaks from your app. It makes phishing your users easier.

1. Signed out, open $STAGING_URL/login?next=https://example.org.
2. Sign in as user A with the emailed link.
3. The browser ends up on example.org.

Only accept a path inside the app.

const { searchParams, origin } = new URL(request.url);
const next = searchParams.get('next') ?? '/dashboard';

const isLocalPath =
  next.startsWith('/') && !next.startsWith('//') && !next.includes('\\');

return NextResponse.redirect(
  new URL(isLocalPath ? next : '/dashboard', origin)
);

The two extra tests matter. Browsers treat //example.org and /\example.org as another site.

No. It needs the user to click a link someone sent them.

app/api/stripe/webhook/route.ts. On invoice.paid the handler adds one month to organizations.paid_until. It does not remember which events it has already handled.

Stripe sends an event again when your server answers slowly or with an error. That is normal behaviour. Each repeat gives the customer another free month. No attacker is needed and no data is exposed.

1. Complete a test checkout as user B. Note paid_until for Org B.
2. Find the invoice.paid event id in the Stripe test dashboard and resend it:

   stripe events resend EVENT_ID

3. paid_until has moved one more month.

Record each event id and skip the ones you have seen.

create table public.stripe_events (
  id text primary key,
  received_at timestamptz not null default now()
);

alter table public.stripe_events enable row level security;

// after the signature check, with the service role client
const { error } = await admin.from('stripe_events').insert({ id: event.id });

if (error?.code === '23505') {
  return new Response(null, { status: 200 }); // already handled
}
if (error) {
  return new Response('Database error', { status: 500 });
}

23505 is the Postgres code for a duplicate key. Row-level security with no policies keeps the table closed to everyone except the server. Better still, set paid_until from the period end date Stripe sends, so a repeat writes the same value.

Yes. It needs Stripe to deliver an event more than once.

Supabase project settings, and the supabase/migrations folder. The staging project has no automatic backups on its current plan. Production is out of scope, so I could not look. Rolling the app back to the previous release works. The database is different: migrations only go forward, and no one has restored a backup.

A bad migration or a mistaken delete could lose customer invoices with no way back. This is not something an attacker does. It is the ordinary bad day.

1. Open the production project in Supabase. Under Database, look at Backups. Confirm that daily backups are listed.
2. Once, before launch, restore a backup into a new empty project and open the app against it. Until you have done that, you do not know the backups work.
3. Before any migration that drops or rewrites a column, take a manual copy:

   pg_dump "$DATABASE_URL" --format=custom --file=before-migration.dump

No.