Full launch report

Security fix: a Stripe secret key (sk_ / rk_) is exposed in the frontend bundle.
1) Find every place the key is read or hard-coded (search for the key prefix, STRIPE_SECRET_KEY, and any VITE_/NEXT_PUBLIC_/REACT_APP_/EXPO_PUBLIC_ variant of it).
2) Move every call that uses it into server-only code (API route, server action, or Supabase Edge Function) that reads STRIPE_SECRET_KEY from a private env var. Never prefix it with VITE_ or NEXT_PUBLIC_.
3) Change the frontend to call that server endpoint instead, and require a logged-in user plus basic rate limiting on it.
4) Remove the old public env var from .env files and from the hosting dashboard.
IMPORTANT: removing the key from code is not enough. The old key is already public, so I will rotate it myself in Stripe Dashboard > Developers > API keys (roll the key); remind me at the end.

How to check it worked: Rebuild, open the live site, and search the JS files in DevTools > Sources for the key prefix. It should not appear.

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Security fix: my Stripe secret key (sk_ / rk_) is visible in the browser code. Move everything that uses it into a secure backend/edge function, store it as a private secret named STRIPE_SECRET_KEY (not a public/VITE_/NEXT_PUBLIC_ variable), make the frontend call that function instead, and remove the key from all client code. IMPORTANT: removing the key from code is not enough. The old key is already public, so I will rotate it myself in Stripe Dashboard > Developers > API keys (roll the key); remind me at the end.

How to check it worked: Rebuild, open the live site, and search the JS files in DevTools > Sources for the key prefix. It should not appear.

Apply this to my project, keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Security fix: my Stripe secret key (sk_ / rk_) is visible in the browser code. Move everything that uses it into a secure backend/edge function, store it as a private secret named STRIPE_SECRET_KEY (not a public/VITE_/NEXT_PUBLIC_ variable), make the frontend call that function instead, and remove the key from all client code. IMPORTANT: removing the key from code is not enough. The old key is already public, so I will rotate it myself in Stripe Dashboard > Developers > API keys (roll the key); remind me at the end.

How to check it worked: Rebuild, open the live site, and search the JS files in DevTools > Sources for the key prefix. It should not appear.

Make the change in this project, keep existing features working, and list anything I must do myself (dashboards, key rotation).

Security fix: my Stripe secret key (sk_ / rk_) is visible in the browser code. Move everything that uses it into a secure backend/edge function, store it as a private secret named STRIPE_SECRET_KEY (not a public/VITE_/NEXT_PUBLIC_ variable), make the frontend call that function instead, and remove the key from all client code. IMPORTANT: removing the key from code is not enough. The old key is already public, so I will rotate it myself in Stripe Dashboard > Developers > API keys (roll the key); remind me at the end.

How to check it worked: Rebuild, open the live site, and search the JS files in DevTools > Sources for the key prefix. It should not appear.

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

CRITICAL: the Supabase table public.profiles is readable with only the anon key. It has sensitive columns: email, phone, stripe_customer_id.
Goal: each signed-in user can only read and edit their own rows; logged-out visitors get nothing.
1) Create a migration (supabase/migrations/<timestamp>_rls_profiles.sql) with exactly this SQL and apply it (supabase db push, or run it in the SQL editor):

-- Fix anonymous access to public.profiles
-- 1) Turn on Row Level Security (denies everything until a policy allows it)
alter table public.profiles enable row level security;
-- 2) First delete any "allow all" / "true" policies on profiles: Dashboard > Authentication > Policies
--    (list them with: select policyname, roles, cmd, qual from pg_policies where tablename = 'profiles';)
-- 3) Logged-out visitors get nothing
revoke all on table public.profiles from anon;
-- 4) Each signed-in user can read and edit only their own row(s)
create policy "profiles_select_own" on public.profiles for select to authenticated using ((select auth.uid()) = id);
create policy "profiles_insert_own" on public.profiles for insert to authenticated with check ((select auth.uid()) = id);
create policy "profiles_update_own" on public.profiles for update to authenticated using ((select auth.uid()) = id) with check ((select auth.uid()) = id);

-- Check: every table in public should show rowsecurity = true
select tablename, rowsecurity from pg_tables where schemaname = 'public' order by rowsecurity, tablename;

2) Find every supabase.from('profiles') call and make sure it runs with a logged-in session; move anything that must read other users' rows into a server route / Edge Function using the service role key.
3) Check every other table the app uses for the same problem.

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/profiles?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Security fix: anyone can read my Supabase table "profiles" without logging in. Turn on Row Level Security for it so that each signed-in user can only read and edit their own rows; logged-out visitors get nothing. Use this SQL as the migration (adjust the owner column if it is named differently):

-- Fix anonymous access to public.profiles
-- 1) Turn on Row Level Security (denies everything until a policy allows it)
alter table public.profiles enable row level security;
-- 2) First delete any "allow all" / "true" policies on profiles: Dashboard > Authentication > Policies
--    (list them with: select policyname, roles, cmd, qual from pg_policies where tablename = 'profiles';)
-- 3) Logged-out visitors get nothing
revoke all on table public.profiles from anon;
-- 4) Each signed-in user can read and edit only their own row(s)
create policy "profiles_select_own" on public.profiles for select to authenticated using ((select auth.uid()) = id);
create policy "profiles_insert_own" on public.profiles for insert to authenticated with check ((select auth.uid()) = id);
create policy "profiles_update_own" on public.profiles for update to authenticated using ((select auth.uid()) = id) with check ((select auth.uid()) = id);

-- Check: every table in public should show rowsecurity = true
select tablename, rowsecurity from pg_tables where schemaname = 'public' order by rowsecurity, tablename;

Then make sure the app still works for logged-in users, and check my other tables for the same problem.

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/profiles?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Apply this to my project (run the SQL as a Supabase migration on the connected project), keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Security fix: anyone can read my Supabase table "profiles" without logging in. Turn on Row Level Security for it so that each signed-in user can only read and edit their own rows; logged-out visitors get nothing. Use this SQL as the migration (adjust the owner column if it is named differently):

-- Fix anonymous access to public.profiles
-- 1) Turn on Row Level Security (denies everything until a policy allows it)
alter table public.profiles enable row level security;
-- 2) First delete any "allow all" / "true" policies on profiles: Dashboard > Authentication > Policies
--    (list them with: select policyname, roles, cmd, qual from pg_policies where tablename = 'profiles';)
-- 3) Logged-out visitors get nothing
revoke all on table public.profiles from anon;
-- 4) Each signed-in user can read and edit only their own row(s)
create policy "profiles_select_own" on public.profiles for select to authenticated using ((select auth.uid()) = id);
create policy "profiles_insert_own" on public.profiles for insert to authenticated with check ((select auth.uid()) = id);
create policy "profiles_update_own" on public.profiles for update to authenticated using ((select auth.uid()) = id) with check ((select auth.uid()) = id);

-- Check: every table in public should show rowsecurity = true
select tablename, rowsecurity from pg_tables where schemaname = 'public' order by rowsecurity, tablename;

Then make sure the app still works for logged-in users, and check my other tables for the same problem.

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/profiles?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Make the change in this project (put the SQL in a new file under supabase/migrations and apply it to the connected Supabase project), keep existing features working, and list anything I must do myself (dashboards, key rotation).

Security fix: anyone can read my Supabase table "profiles" without logging in. Turn on Row Level Security for it so that each signed-in user can only read and edit their own rows; logged-out visitors get nothing. Use this SQL as the migration (adjust the owner column if it is named differently):

-- Fix anonymous access to public.profiles
-- 1) Turn on Row Level Security (denies everything until a policy allows it)
alter table public.profiles enable row level security;
-- 2) First delete any "allow all" / "true" policies on profiles: Dashboard > Authentication > Policies
--    (list them with: select policyname, roles, cmd, qual from pg_policies where tablename = 'profiles';)
-- 3) Logged-out visitors get nothing
revoke all on table public.profiles from anon;
-- 4) Each signed-in user can read and edit only their own row(s)
create policy "profiles_select_own" on public.profiles for select to authenticated using ((select auth.uid()) = id);
create policy "profiles_insert_own" on public.profiles for insert to authenticated with check ((select auth.uid()) = id);
create policy "profiles_update_own" on public.profiles for update to authenticated using ((select auth.uid()) = id) with check ((select auth.uid()) = id);

-- Check: every table in public should show rowsecurity = true
select tablename, rowsecurity from pg_tables where schemaname = 'public' order by rowsecurity, tablename;

Then make sure the app still works for logged-in users, and check my other tables for the same problem.

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/profiles?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

CRITICAL: the Supabase table public.payments is readable with only the anon key. It has sensitive columns: stripe_customer_id.
Goal: logged-out visitors get nothing, signed-in users can only read their own rows, and rows are only written by the server/webhook with the service role key.
1) Create a migration (supabase/migrations/<timestamp>_rls_payments.sql) with exactly this SQL and apply it (supabase db push, or run it in the SQL editor):

-- Fix anonymous access to public.payments
-- 1) Turn on Row Level Security (denies everything until a policy allows it)
alter table public.payments enable row level security;
-- 2) First delete any "allow all" / "true" policies on payments: Dashboard > Authentication > Policies
--    (list them with: select policyname, roles, cmd, qual from pg_policies where tablename = 'payments';)
-- 3) Logged-out visitors get nothing
revoke all on table public.payments from anon;
-- 4) Signed-in users can read only their own rows
create policy "payments_select_own" on public.payments for select to authenticated using ((select auth.uid()) = user_id);
-- 5) No insert/update/delete policies on purpose: write these rows only from your server
--    or Stripe webhook using the service role key (never from the browser).

-- Check: every table in public should show rowsecurity = true
select tablename, rowsecurity from pg_tables where schemaname = 'public' order by rowsecurity, tablename;

2) Find every supabase.from('payments') call and make sure it runs with a logged-in session; move anything that must read other users' rows into a server route / Edge Function using the service role key.
3) Check every other table the app uses for the same problem.

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/payments?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Security fix: anyone can read my Supabase table "payments" without logging in. Turn on Row Level Security for it so that logged-out visitors get nothing, signed-in users can only read their own rows, and rows are only written by the server/webhook with the service role key. Use this SQL as the migration (adjust the owner column if it is named differently):

-- Fix anonymous access to public.payments
-- 1) Turn on Row Level Security (denies everything until a policy allows it)
alter table public.payments enable row level security;
-- 2) First delete any "allow all" / "true" policies on payments: Dashboard > Authentication > Policies
--    (list them with: select policyname, roles, cmd, qual from pg_policies where tablename = 'payments';)
-- 3) Logged-out visitors get nothing
revoke all on table public.payments from anon;
-- 4) Signed-in users can read only their own rows
create policy "payments_select_own" on public.payments for select to authenticated using ((select auth.uid()) = user_id);
-- 5) No insert/update/delete policies on purpose: write these rows only from your server
--    or Stripe webhook using the service role key (never from the browser).

-- Check: every table in public should show rowsecurity = true
select tablename, rowsecurity from pg_tables where schemaname = 'public' order by rowsecurity, tablename;

Then make sure the app still works for logged-in users, and check my other tables for the same problem.

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/payments?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Apply this to my project (run the SQL as a Supabase migration on the connected project), keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Security fix: anyone can read my Supabase table "payments" without logging in. Turn on Row Level Security for it so that logged-out visitors get nothing, signed-in users can only read their own rows, and rows are only written by the server/webhook with the service role key. Use this SQL as the migration (adjust the owner column if it is named differently):

-- Fix anonymous access to public.payments
-- 1) Turn on Row Level Security (denies everything until a policy allows it)
alter table public.payments enable row level security;
-- 2) First delete any "allow all" / "true" policies on payments: Dashboard > Authentication > Policies
--    (list them with: select policyname, roles, cmd, qual from pg_policies where tablename = 'payments';)
-- 3) Logged-out visitors get nothing
revoke all on table public.payments from anon;
-- 4) Signed-in users can read only their own rows
create policy "payments_select_own" on public.payments for select to authenticated using ((select auth.uid()) = user_id);
-- 5) No insert/update/delete policies on purpose: write these rows only from your server
--    or Stripe webhook using the service role key (never from the browser).

-- Check: every table in public should show rowsecurity = true
select tablename, rowsecurity from pg_tables where schemaname = 'public' order by rowsecurity, tablename;

Then make sure the app still works for logged-in users, and check my other tables for the same problem.

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/payments?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Make the change in this project (put the SQL in a new file under supabase/migrations and apply it to the connected Supabase project), keep existing features working, and list anything I must do myself (dashboards, key rotation).

Security fix: anyone can read my Supabase table "payments" without logging in. Turn on Row Level Security for it so that logged-out visitors get nothing, signed-in users can only read their own rows, and rows are only written by the server/webhook with the service role key. Use this SQL as the migration (adjust the owner column if it is named differently):

-- Fix anonymous access to public.payments
-- 1) Turn on Row Level Security (denies everything until a policy allows it)
alter table public.payments enable row level security;
-- 2) First delete any "allow all" / "true" policies on payments: Dashboard > Authentication > Policies
--    (list them with: select policyname, roles, cmd, qual from pg_policies where tablename = 'payments';)
-- 3) Logged-out visitors get nothing
revoke all on table public.payments from anon;
-- 4) Signed-in users can read only their own rows
create policy "payments_select_own" on public.payments for select to authenticated using ((select auth.uid()) = user_id);
-- 5) No insert/update/delete policies on purpose: write these rows only from your server
--    or Stripe webhook using the service role key (never from the browser).

-- Check: every table in public should show rowsecurity = true
select tablename, rowsecurity from pg_tables where schemaname = 'public' order by rowsecurity, tablename;

Then make sure the app still works for logged-in users, and check my other tables for the same problem.

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/payments?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

Supabase Storage bucket "invoices" can be listed anonymously. Write and apply a migration with this SQL (adjust the folder convention if files are not stored under <user id>/...):

-- 1) Find the policy that lets anyone list files in "invoices"
select policyname, roles, cmd, qual from pg_policies where schemaname = 'storage' and tablename = 'objects';
-- 2) Drop the over-broad one(s), e.g.:
-- drop policy "<policy name>" on storage.objects;
-- 3) Owner-only access: files live under a folder named after the user id (<uid>/file.png)
create policy "invoices_read_own" on storage.objects for select to authenticated
  using (bucket_id = 'invoices' and (storage.foldername(name))[1] = (select auth.uid())::text);
create policy "invoices_upload_own" on storage.objects for insert to authenticated
  with check (bucket_id = 'invoices' and (storage.foldername(name))[1] = (select auth.uid())::text);
-- If these files are meant to be public (e.g. avatars), make the bucket public for downloads instead of adding an anon SELECT policy: public URLs work without one and nobody can list the folder.

Then update upload code to save files at `${user.id}/<filename>`, and use createSignedUrl() for private downloads.

How to check it worked: curl -X POST "https://YOUR_PROJECT.supabase.co/storage/v1/object/list/invoices" -H "apikey: YOUR_ANON_KEY" -H "Authorization: Bearer YOUR_ANON_KEY" -H "Content-Type: application/json" -d '{"prefix":"","limit":1}'   # expect []

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Security fix: anyone can list the files in my Supabase Storage bucket "invoices" without logging in. Remove the public listing policy and make files private per user (stored in a folder named after the user id, readable only by that user, shared with signed URLs). Use this SQL:

-- 1) Find the policy that lets anyone list files in "invoices"
select policyname, roles, cmd, qual from pg_policies where schemaname = 'storage' and tablename = 'objects';
-- 2) Drop the over-broad one(s), e.g.:
-- drop policy "<policy name>" on storage.objects;
-- 3) Owner-only access: files live under a folder named after the user id (<uid>/file.png)
create policy "invoices_read_own" on storage.objects for select to authenticated
  using (bucket_id = 'invoices' and (storage.foldername(name))[1] = (select auth.uid())::text);
create policy "invoices_upload_own" on storage.objects for insert to authenticated
  with check (bucket_id = 'invoices' and (storage.foldername(name))[1] = (select auth.uid())::text);
-- If these files are meant to be public (e.g. avatars), make the bucket public for downloads instead of adding an anon SELECT policy: public URLs work without one and nobody can list the folder.

How to check it worked: curl -X POST "https://YOUR_PROJECT.supabase.co/storage/v1/object/list/invoices" -H "apikey: YOUR_ANON_KEY" -H "Authorization: Bearer YOUR_ANON_KEY" -H "Content-Type: application/json" -d '{"prefix":"","limit":1}'   # expect []

Apply this to my project (run the SQL as a Supabase migration on the connected project), keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Security fix: anyone can list the files in my Supabase Storage bucket "invoices" without logging in. Remove the public listing policy and make files private per user (stored in a folder named after the user id, readable only by that user, shared with signed URLs). Use this SQL:

-- 1) Find the policy that lets anyone list files in "invoices"
select policyname, roles, cmd, qual from pg_policies where schemaname = 'storage' and tablename = 'objects';
-- 2) Drop the over-broad one(s), e.g.:
-- drop policy "<policy name>" on storage.objects;
-- 3) Owner-only access: files live under a folder named after the user id (<uid>/file.png)
create policy "invoices_read_own" on storage.objects for select to authenticated
  using (bucket_id = 'invoices' and (storage.foldername(name))[1] = (select auth.uid())::text);
create policy "invoices_upload_own" on storage.objects for insert to authenticated
  with check (bucket_id = 'invoices' and (storage.foldername(name))[1] = (select auth.uid())::text);
-- If these files are meant to be public (e.g. avatars), make the bucket public for downloads instead of adding an anon SELECT policy: public URLs work without one and nobody can list the folder.

How to check it worked: curl -X POST "https://YOUR_PROJECT.supabase.co/storage/v1/object/list/invoices" -H "apikey: YOUR_ANON_KEY" -H "Authorization: Bearer YOUR_ANON_KEY" -H "Content-Type: application/json" -d '{"prefix":"","limit":1}'   # expect []

Make the change in this project (put the SQL in a new file under supabase/migrations and apply it to the connected Supabase project), keep existing features working, and list anything I must do myself (dashboards, key rotation).

Security fix: anyone can list the files in my Supabase Storage bucket "invoices" without logging in. Remove the public listing policy and make files private per user (stored in a folder named after the user id, readable only by that user, shared with signed URLs). Use this SQL:

-- 1) Find the policy that lets anyone list files in "invoices"
select policyname, roles, cmd, qual from pg_policies where schemaname = 'storage' and tablename = 'objects';
-- 2) Drop the over-broad one(s), e.g.:
-- drop policy "<policy name>" on storage.objects;
-- 3) Owner-only access: files live under a folder named after the user id (<uid>/file.png)
create policy "invoices_read_own" on storage.objects for select to authenticated
  using (bucket_id = 'invoices' and (storage.foldername(name))[1] = (select auth.uid())::text);
create policy "invoices_upload_own" on storage.objects for insert to authenticated
  with check (bucket_id = 'invoices' and (storage.foldername(name))[1] = (select auth.uid())::text);
-- If these files are meant to be public (e.g. avatars), make the bucket public for downloads instead of adding an anon SELECT policy: public URLs work without one and nobody can list the folder.

How to check it worked: curl -X POST "https://YOUR_PROJECT.supabase.co/storage/v1/object/list/invoices" -H "apikey: YOUR_ANON_KEY" -H "Authorization: Bearer YOUR_ANON_KEY" -H "Content-Type: application/json" -d '{"prefix":"","limit":1}'   # expect []

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

Add a Content-Security-Policy header. Start with Content-Security-Policy-Report-Only so nothing breaks:
default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://*.supabase.co; frame-ancestors 'none'; base-uri 'self'; object-src 'none'
List every third-party domain the app actually loads (analytics, fonts, Stripe, Supabase) and add them to the right directive. Check the browser console for violations, then switch to the enforcing Content-Security-Policy header (vercel.json headers, netlify.toml, or next.config.js headers()).

How to check it worked: curl -sI https://your-site.com | grep -i content-security-policy

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Add a Content-Security-Policy header to my site to reduce XSS risk. Start in report-only mode with default-src 'self', add the third-party domains my app really uses (Supabase, Stripe, fonts, analytics), and tell me when it's safe to enforce it.

How to check it worked: curl -sI https://your-site.com | grep -i content-security-policy

Apply this to my project, keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Add a Content-Security-Policy header to my site to reduce XSS risk. Start in report-only mode with default-src 'self', add the third-party domains my app really uses (Supabase, Stripe, fonts, analytics), and tell me when it's safe to enforce it.

How to check it worked: curl -sI https://your-site.com | grep -i content-security-policy

Make the change in this project, keep existing features working, and list anything I must do myself (dashboards, key rotation).

Add a Content-Security-Policy header to my site to reduce XSS risk. Start in report-only mode with default-src 'self', add the third-party domains my app really uses (Supabase, Stripe, fonts, analytics), and tell me when it's safe to enforce it.

How to check it worked: curl -sI https://your-site.com | grep -i content-security-policy

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

Upgrade a vulnerable client library: jQuery 3.4.1 is in the deployed bundle.
Advisories:
- CVE-2020-11022 (fixed in 3.5.0): https://nvd.nist.gov/vuln/detail/CVE-2020-11022
Find where jQuery comes from: a package.json dependency ("npm ls jquery" shows which package pulls it in), a CDN <script> tag, or a WordPress/theme bundle. Upgrade to 3.7.1 or later (npm install jquery@latest, or update the CDN URL), run "npm audit" for other advisories, rebuild and redeploy. Read the jQuery 3.5 upgrade guide: htmlPrefilter changed, so test pages that inject HTML.

How to check it worked: View the live JS in DevTools > Sources and confirm the jQuery version banner shows the new version, then re-scan.

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

My live site uses jQuery 3.4.1, which has known security vulnerabilities (CVE-2020-11022). Upgrade it to the latest safe version, fix anything the upgrade breaks, and tell me how to confirm the new version is live.

How to check it worked: View the live JS in DevTools > Sources and confirm the jQuery version banner shows the new version, then re-scan.

Apply this to my project, keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

My live site uses jQuery 3.4.1, which has known security vulnerabilities (CVE-2020-11022). Upgrade it to the latest safe version, fix anything the upgrade breaks, and tell me how to confirm the new version is live.

How to check it worked: View the live JS in DevTools > Sources and confirm the jQuery version banner shows the new version, then re-scan.

Make the change in this project, keep existing features working, and list anything I must do myself (dashboards, key rotation).

My live site uses jQuery 3.4.1, which has known security vulnerabilities (CVE-2020-11022). Upgrade it to the latest safe version, fix anything the upgrade breaks, and tell me how to confirm the new version is live.

How to check it worked: View the live JS in DevTools > Sources and confirm the jQuery version banner shows the new version, then re-scan.

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

Disable public production source maps: Vite build.sourcemap = false (or "hidden" and upload to your error tracker); Next.js productionBrowserSourceMaps: false; CRA GENERATE_SOURCEMAP=false. Make sure no *.map files are in the deploy output.

How to check it worked: Open one of the .map URLs from the report: it should be 404.

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Turn off source maps for production builds so my original source code is not downloadable, and redeploy.

How to check it worked: Open one of the .map URLs from the report: it should be 404.

Apply this to my project, keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Turn off source maps for production builds so my original source code is not downloadable, and redeploy.

How to check it worked: Open one of the .map URLs from the report: it should be 404.

Make the change in this project, keep existing features working, and list anything I must do myself (dashboards, key rotation).

Turn off source maps for production builds so my original source code is not downloadable, and redeploy.

How to check it worked: Open one of the .map URLs from the report: it should be 404.

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

CRITICAL: the Supabase table public.posts is readable with only the anon key.
Goal: everyone can read it (it is public content), but only the author can create, edit or delete their own rows.
1) Create a migration (supabase/migrations/<timestamp>_rls_posts.sql) with exactly this SQL and apply it (supabase db push, or run it in the SQL editor):

-- Fix anonymous access to public.posts
-- 1) Turn on Row Level Security (denies everything until a policy allows it)
alter table public.posts enable row level security;
-- 2) First delete any "allow all" / "true" policies on posts: Dashboard > Authentication > Policies
--    (list them with: select policyname, roles, cmd, qual from pg_policies where tablename = 'posts';)
-- 3) Everyone may read (add "using (published = true)" instead of "true" if you have drafts)
create policy "posts_public_read" on public.posts for select to anon, authenticated using (true);
-- 4) Only the author can write
create policy "posts_insert_own" on public.posts for insert to authenticated with check ((select auth.uid()) = author_id);
create policy "posts_update_own" on public.posts for update to authenticated using ((select auth.uid()) = author_id) with check ((select auth.uid()) = author_id);
create policy "posts_delete_own" on public.posts for delete to authenticated using ((select auth.uid()) = author_id);

-- Check: every table in public should show rowsecurity = true
select tablename, rowsecurity from pg_tables where schemaname = 'public' order by rowsecurity, tablename;

2) Find every supabase.from('posts') call and make sure it runs with a logged-in session; move anything that must read other users' rows into a server route / Edge Function using the service role key.
3) Check every other table the app uses for the same problem.

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/posts?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Security fix: anyone can read my Supabase table "posts" without logging in. Turn on Row Level Security for it so that everyone can read it (it is public content), but only the author can create, edit or delete their own rows. Use this SQL as the migration (adjust the owner column if it is named differently):

-- Fix anonymous access to public.posts
-- 1) Turn on Row Level Security (denies everything until a policy allows it)
alter table public.posts enable row level security;
-- 2) First delete any "allow all" / "true" policies on posts: Dashboard > Authentication > Policies
--    (list them with: select policyname, roles, cmd, qual from pg_policies where tablename = 'posts';)
-- 3) Everyone may read (add "using (published = true)" instead of "true" if you have drafts)
create policy "posts_public_read" on public.posts for select to anon, authenticated using (true);
-- 4) Only the author can write
create policy "posts_insert_own" on public.posts for insert to authenticated with check ((select auth.uid()) = author_id);
create policy "posts_update_own" on public.posts for update to authenticated using ((select auth.uid()) = author_id) with check ((select auth.uid()) = author_id);
create policy "posts_delete_own" on public.posts for delete to authenticated using ((select auth.uid()) = author_id);

-- Check: every table in public should show rowsecurity = true
select tablename, rowsecurity from pg_tables where schemaname = 'public' order by rowsecurity, tablename;

Then make sure the app still works for logged-in users, and check my other tables for the same problem.

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/posts?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Apply this to my project (run the SQL as a Supabase migration on the connected project), keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Security fix: anyone can read my Supabase table "posts" without logging in. Turn on Row Level Security for it so that everyone can read it (it is public content), but only the author can create, edit or delete their own rows. Use this SQL as the migration (adjust the owner column if it is named differently):

-- Fix anonymous access to public.posts
-- 1) Turn on Row Level Security (denies everything until a policy allows it)
alter table public.posts enable row level security;
-- 2) First delete any "allow all" / "true" policies on posts: Dashboard > Authentication > Policies
--    (list them with: select policyname, roles, cmd, qual from pg_policies where tablename = 'posts';)
-- 3) Everyone may read (add "using (published = true)" instead of "true" if you have drafts)
create policy "posts_public_read" on public.posts for select to anon, authenticated using (true);
-- 4) Only the author can write
create policy "posts_insert_own" on public.posts for insert to authenticated with check ((select auth.uid()) = author_id);
create policy "posts_update_own" on public.posts for update to authenticated using ((select auth.uid()) = author_id) with check ((select auth.uid()) = author_id);
create policy "posts_delete_own" on public.posts for delete to authenticated using ((select auth.uid()) = author_id);

-- Check: every table in public should show rowsecurity = true
select tablename, rowsecurity from pg_tables where schemaname = 'public' order by rowsecurity, tablename;

Then make sure the app still works for logged-in users, and check my other tables for the same problem.

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/posts?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Make the change in this project (put the SQL in a new file under supabase/migrations and apply it to the connected Supabase project), keep existing features working, and list anything I must do myself (dashboards, key rotation).

Security fix: anyone can read my Supabase table "posts" without logging in. Turn on Row Level Security for it so that everyone can read it (it is public content), but only the author can create, edit or delete their own rows. Use this SQL as the migration (adjust the owner column if it is named differently):

-- Fix anonymous access to public.posts
-- 1) Turn on Row Level Security (denies everything until a policy allows it)
alter table public.posts enable row level security;
-- 2) First delete any "allow all" / "true" policies on posts: Dashboard > Authentication > Policies
--    (list them with: select policyname, roles, cmd, qual from pg_policies where tablename = 'posts';)
-- 3) Everyone may read (add "using (published = true)" instead of "true" if you have drafts)
create policy "posts_public_read" on public.posts for select to anon, authenticated using (true);
-- 4) Only the author can write
create policy "posts_insert_own" on public.posts for insert to authenticated with check ((select auth.uid()) = author_id);
create policy "posts_update_own" on public.posts for update to authenticated using ((select auth.uid()) = author_id) with check ((select auth.uid()) = author_id);
create policy "posts_delete_own" on public.posts for delete to authenticated using ((select auth.uid()) = author_id);

-- Check: every table in public should show rowsecurity = true
select tablename, rowsecurity from pg_tables where schemaname = 'public' order by rowsecurity, tablename;

Then make sure the app still works for logged-in users, and check my other tables for the same problem.

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/posts?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

Add the response header "X-Frame-Options: DENY" to every HTML response.
- Vercel: add it under "headers" for source "/(.*)" in vercel.json
- Netlify: add it to _headers or netlify.toml
- Next.js: add it in next.config.js async headers()
- Express: res.setHeader in a global middleware
Do not change anything else.

How to check it worked: curl -sI https://your-site.com | grep -i "X-Frame-Options"

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Add the security header "X-Frame-Options: DENY" to every page of my site, using the hosting config (vercel.json, netlify.toml or next.config.js). Don't change anything else.

How to check it worked: curl -sI https://your-site.com | grep -i "X-Frame-Options"

Apply this to my project, keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Add the security header "X-Frame-Options: DENY" to every page of my site, using the hosting config (vercel.json, netlify.toml or next.config.js). Don't change anything else.

How to check it worked: curl -sI https://your-site.com | grep -i "X-Frame-Options"

Make the change in this project, keep existing features working, and list anything I must do myself (dashboards, key rotation).

Add the security header "X-Frame-Options: DENY" to every page of my site, using the hosting config (vercel.json, netlify.toml or next.config.js). Don't change anything else.

How to check it worked: curl -sI https://your-site.com | grep -i "X-Frame-Options"

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

Add the response header "X-Content-Type-Options: nosniff" to every HTML response.
- Vercel: add it under "headers" for source "/(.*)" in vercel.json
- Netlify: add it to _headers or netlify.toml
- Next.js: add it in next.config.js async headers()
- Express: res.setHeader in a global middleware
Do not change anything else.

How to check it worked: curl -sI https://your-site.com | grep -i "X-Content-Type-Options"

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Add the security header "X-Content-Type-Options: nosniff" to every page of my site, using the hosting config (vercel.json, netlify.toml or next.config.js). Don't change anything else.

How to check it worked: curl -sI https://your-site.com | grep -i "X-Content-Type-Options"

Apply this to my project, keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Add the security header "X-Content-Type-Options: nosniff" to every page of my site, using the hosting config (vercel.json, netlify.toml or next.config.js). Don't change anything else.

How to check it worked: curl -sI https://your-site.com | grep -i "X-Content-Type-Options"

Make the change in this project, keep existing features working, and list anything I must do myself (dashboards, key rotation).

Add the security header "X-Content-Type-Options: nosniff" to every page of my site, using the hosting config (vercel.json, netlify.toml or next.config.js). Don't change anything else.

How to check it worked: curl -sI https://your-site.com | grep -i "X-Content-Type-Options"

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

Add <meta name="description" content="..."> (140-160 chars) to index.html, or metadata.description in the Next.js root layout.

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Add a one-sentence meta description that explains what my app does, for Google and link previews.

Apply this to my project, keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Add a one-sentence meta description that explains what my app does, for Google and link previews.

Make the change in this project, keep existing features working, and list anything I must do myself (dashboards, key rotation).

Add a one-sentence meta description that explains what my app does, for Google and link previews.

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

Tighten CORS: the server reflects any Origin header into Access-Control-Allow-Origin. Replace the reflect-all setting with an allowlist of your own domains (or omit CORS headers entirely on HTML pages that do not need them), add "Vary: Origin", and make sure no route combines a reflected origin with Access-Control-Allow-Credentials: true.

How to check it worked: curl -s -o /dev/null -D - -H "Origin: https://evil.example" https://your-site.com | grep -i access-control

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

My site answers CORS requests from any website. Limit Access-Control-Allow-Origin to my own domains (or remove CORS headers where they are not needed) and make sure credentials are never allowed for other origins.

How to check it worked: curl -s -o /dev/null -D - -H "Origin: https://evil.example" https://your-site.com | grep -i access-control

Apply this to my project, keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

My site answers CORS requests from any website. Limit Access-Control-Allow-Origin to my own domains (or remove CORS headers where they are not needed) and make sure credentials are never allowed for other origins.

How to check it worked: curl -s -o /dev/null -D - -H "Origin: https://evil.example" https://your-site.com | grep -i access-control

Make the change in this project, keep existing features working, and list anything I must do myself (dashboards, key rotation).

My site answers CORS requests from any website. Limit Access-Control-Allow-Origin to my own domains (or remove CORS headers where they are not needed) and make sure credentials are never allowed for other origins.

How to check it worked: curl -s -o /dev/null -D - -H "Origin: https://evil.example" https://your-site.com | grep -i access-control

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

The Supabase REST schema (/rest/v1/) lists our tables to anonymous users (profiles, payments, posts, messages, waitlist, admin_settings).
1) Enable RLS on every table in public and add auth.uid()-scoped policies (find gaps with: select tablename from pg_tables where schemaname='public' and not rowsecurity;).
2) Move internal/admin tables to a private schema that is not in "Exposed schemas" (Project Settings > API), or revoke anon access: revoke all on table public.<name> from anon;
3) Write the SQL as a migration file and apply it.

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Anyone can see my Supabase table names. Make sure Row Level Security is on for every table with policies so users only see their own data, and stop exposing internal/admin tables to the public API (revoke access for the anon role).

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Apply this to my project (run the SQL as a Supabase migration on the connected project), keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Anyone can see my Supabase table names. Make sure Row Level Security is on for every table with policies so users only see their own data, and stop exposing internal/admin tables to the public API (revoke access for the anon role).

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Make the change in this project (put the SQL in a new file under supabase/migrations and apply it to the connected Supabase project), keep existing features working, and list anything I must do myself (dashboards, key rotation).

Anyone can see my Supabase table names. Make sure Row Level Security is on for every table with policies so users only see their own data, and stop exposing internal/admin tables to the public API (revoke access for the anon role).

How to check it worked: curl "https://abcdefghijklmnopqrst.supabase.co/rest/v1/?select=*&limit=1" -H "apikey: YOUR_ANON_KEY"   # expect [] or a 401/permission error

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

Supabase Storage bucket metadata can be listed anonymously. Write and apply a migration with this SQL (adjust the folder convention if files are not stored under <user id>/...):

-- Who can list buckets? Drop any policy that lets anon read storage.buckets:
select policyname, roles, cmd, qual from pg_policies where schemaname = 'storage' and tablename = 'buckets';
-- drop policy "<policy name>" on storage.buckets;
-- Then check object policies (listing files) the same way:
select policyname, roles, cmd, qual from pg_policies where schemaname = 'storage' and tablename = 'objects';

Then update upload code to save files at `${user.id}/<filename>`, and use createSignedUrl() for private downloads.

How to check it worked: curl -X POST "https://abcdefghijklmnopqrst.supabase.co/storage/v1/object/list/invoices" -H "apikey: YOUR_ANON_KEY" -H "Authorization: Bearer YOUR_ANON_KEY" -H "Content-Type: application/json" -d '{"prefix":"","limit":1}'   # expect []

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Security fix: anyone can list my Supabase Storage buckets without logging in. Remove the public listing policy and make files private per user (stored in a folder named after the user id, readable only by that user, shared with signed URLs). Use this SQL:

-- Who can list buckets? Drop any policy that lets anon read storage.buckets:
select policyname, roles, cmd, qual from pg_policies where schemaname = 'storage' and tablename = 'buckets';
-- drop policy "<policy name>" on storage.buckets;
-- Then check object policies (listing files) the same way:
select policyname, roles, cmd, qual from pg_policies where schemaname = 'storage' and tablename = 'objects';

How to check it worked: curl -X POST "https://abcdefghijklmnopqrst.supabase.co/storage/v1/object/list/invoices" -H "apikey: YOUR_ANON_KEY" -H "Authorization: Bearer YOUR_ANON_KEY" -H "Content-Type: application/json" -d '{"prefix":"","limit":1}'   # expect []

Apply this to my project (run the SQL as a Supabase migration on the connected project), keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Security fix: anyone can list my Supabase Storage buckets without logging in. Remove the public listing policy and make files private per user (stored in a folder named after the user id, readable only by that user, shared with signed URLs). Use this SQL:

-- Who can list buckets? Drop any policy that lets anon read storage.buckets:
select policyname, roles, cmd, qual from pg_policies where schemaname = 'storage' and tablename = 'buckets';
-- drop policy "<policy name>" on storage.buckets;
-- Then check object policies (listing files) the same way:
select policyname, roles, cmd, qual from pg_policies where schemaname = 'storage' and tablename = 'objects';

How to check it worked: curl -X POST "https://abcdefghijklmnopqrst.supabase.co/storage/v1/object/list/invoices" -H "apikey: YOUR_ANON_KEY" -H "Authorization: Bearer YOUR_ANON_KEY" -H "Content-Type: application/json" -d '{"prefix":"","limit":1}'   # expect []

Make the change in this project (put the SQL in a new file under supabase/migrations and apply it to the connected Supabase project), keep existing features working, and list anything I must do myself (dashboards, key rotation).

Security fix: anyone can list my Supabase Storage buckets without logging in. Remove the public listing policy and make files private per user (stored in a folder named after the user id, readable only by that user, shared with signed URLs). Use this SQL:

-- Who can list buckets? Drop any policy that lets anon read storage.buckets:
select policyname, roles, cmd, qual from pg_policies where schemaname = 'storage' and tablename = 'buckets';
-- drop policy "<policy name>" on storage.buckets;
-- Then check object policies (listing files) the same way:
select policyname, roles, cmd, qual from pg_policies where schemaname = 'storage' and tablename = 'objects';

How to check it worked: curl -X POST "https://abcdefghijklmnopqrst.supabase.co/storage/v1/object/list/invoices" -H "apikey: YOUR_ANON_KEY" -H "Authorization: Bearer YOUR_ANON_KEY" -H "Content-Type: application/json" -d '{"prefix":"","limit":1}'   # expect []

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

The Supabase URL + anon/publishable key are public by design. Audit RLS: list tables without RLS (select tablename from pg_tables where schemaname='public' and not rowsecurity;), enable it on each, and add policies scoped to auth.uid(). Confirm no service_role key is in client code.

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Keep my Supabase URL and anon key, but check that Row Level Security is enabled on every table and that each table has policies so users can only see their own data. Show me any table without RLS.

Apply this to my project, keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Keep my Supabase URL and anon key, but check that Row Level Security is enabled on every table and that each table has policies so users can only see their own data. Show me any table without RLS.

Make the change in this project, keep existing features working, and list anything I must do myself (dashboards, key rotation).

Keep my Supabase URL and anon key, but check that Row Level Security is enabled on every table and that each table has policies so users can only see their own data. Show me any table without RLS.

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

A hard-coded JWT is in the client bundle. Decode it (jwt.io or base64 the middle part) and check its role/claims. If it is anything other than a public anon key (e.g. service_role, admin, a long-lived user/session token), remove it from client code, move the calls that need it to a server route, and revoke/rotate it with whoever issued it.

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

A hard-coded login/API token (JWT) is in my app's browser code. Find it, tell me what it is for, and if it is not a public anon key move it to a secure backend function and remove it from the client.

Apply this to my project, keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

A hard-coded login/API token (JWT) is in my app's browser code. Find it, tell me what it is for, and if it is not a public anon key move it to a secure backend function and remove it from the client.

Make the change in this project, keep existing features working, and list anything I must do myself (dashboards, key rotation).

A hard-coded login/API token (JWT) is in my app's browser code. Find it, tell me what it is for, and if it is not a public anon key move it to a secure backend function and remove it from the client.

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.

Add a security.txt file (RFC 9116) served at /.well-known/security.txt as text/plain:
Contact: mailto:security@your-domain.com
Expires: <a date under 1 year from today, ISO 8601, e.g. 2027-10-01T00:00:00.000Z>
Preferred-Languages: en
Canonical: https://your-app.lovable.app/.well-known/security.txt
Put it in the static folder that is served as-is (public/.well-known/security.txt for Vite, Next.js and most hosts), make sure the router does not swallow /.well-known/, and redeploy.

How to check it worked: curl -s https://your-app.lovable.app/.well-known/security.txt

Search the repo (grep) for every affected file, make the edits, run the build and any tests to confirm nothing broke, then summarize what you changed and the manual steps left for me.

Add a security.txt file at /.well-known/security.txt on my site with a Contact email (ask me which one), an Expires date less than a year from today, Preferred-Languages: en and a Canonical URL. It must be served as plain text.

How to check it worked: curl -s https://your-app.lovable.app/.well-known/security.txt

Apply this to my project, keep the app working for logged-in users, then tell me in plain words anything I must do myself outside Lovable.

Add a security.txt file at /.well-known/security.txt on my site with a Contact email (ask me which one), an Expires date less than a year from today, Preferred-Languages: en and a Canonical URL. It must be served as plain text.

How to check it worked: curl -s https://your-app.lovable.app/.well-known/security.txt

Make the change in this project, keep existing features working, and list anything I must do myself (dashboards, key rotation).

Add a security.txt file at /.well-known/security.txt on my site with a Contact email (ask me which one), an Expires date less than a year from today, Preferred-Languages: en and a Canonical URL. It must be served as plain text.

How to check it worked: curl -s https://your-app.lovable.app/.well-known/security.txt

Apply it to this Next.js project (server-only code in route handlers or server actions, secrets in env vars without NEXT_PUBLIC_), show which files you changed, and list any steps I must do outside v0.