Bolt: contact or sign-up form insert blocked by row-level security

Short answer: Your form's insert is stopped because the row-level security (RLS) policies on that table don't allow visitors to add rows. Ask Bolt to update the policies so visitors can add rows to that table but not read, change, or delete data other people submitted.

Why it happens

Your database stores information in tables. Anyone who visits your site can send requests to your database directly, without using your site's screens. Row-level security decides which rows a request can read or change. When RLS is on, rules called policies say who can access which rows, and a request only gets the access a policy gives it.

If a table has RLS on but no policy that lets visitors add rows, the insert from your form is rejected. Bolt turns on RLS for the tables it creates, so this can happen when the policies on a table don't match what a public form needs.

If you haven't asked Bolt to add sign-in to your site, Bolt might instead write policies that allow any visitor to view, add, change, and delete the data. The Security tab flags a policy with no conditions limiting who can access a row as RLS Policy Always True. Bolt runs the same scan on every project, so it flags this even when public access is what you want.

The Security Audit page checks for missing RLS and policies that are too open, so it may not point at a blocked insert. Look at the policies on the table your form writes to.

How to fix it

1. Log in to your Bolt project.
2. In the top center of your screen, click the database icon. The database settings open to the Tables page.
3. Click the table your form writes to, then click View policies to review the RLS policies applied to it.
4. Decide what the table needs. For contact forms, sign-ups, and reviews, the fitting option is: visitors can submit information, meaning they can add this data but not read, change, or delete data that other people submitted.
5. Ask Bolt to update the policies to match. For example: Update the policies for my database so visitors can only add rows to the contact_messages table. Replace contact_messages with the name of your table.
6. Click the database icon, then click Security. This opens the Security Audit page, which lists any database security issues Bolt finds, most serious first. If it shows issues and you can edit the project, you can click Ask Bolt to fix.
7. Any time you update your database, open the Security page again to check for new issues.

If the form data should stay private, for example customer orders or messages, add sign-in instead. Ask Bolt to add a sign-in form, choose how people sign in (for example with an email address or a Google account), then ask Bolt to update your policies so only signed-in people can access the private data. You can combine these in one request: Add email sign-in to my site. Then update the policies for the orders table so only signed-in people can view, add, change, or delete their orders.

How to check it worked on your live app

Open a private window and use a fresh email address. Go to your live app, not the preview, and submit the contact or sign-up form that was failing. Check whether the submission goes through.

Prompt to paste into your AI builder

Paste this into your AI builder: "My contact form insert is blocked by row-level security. Update the policies for the table my form writes to so visitors can add rows but cannot read, change or delete data that other people submitted. Keep RLS turned on for every table. Show me the policy change first before you apply it."

FAQ

Where do I see the security issues for my database? Log in to your Bolt project, click the database icon in the top center of your screen, then click Security. The page is titled Security Audit and it checks only your database, not your whole project.

What does the RLS Policy Always True warning mean? It means a policy has no conditions that limit who can access a row. Bolt runs the same scan on every project, so it flags this even when public access is what you want. The warning is acceptable only if you're comfortable with every visitor being able to change or delete that data.

Does Bolt turn on RLS for me? Bolt turns on RLS for the tables it creates. If you add any tables in the database, make sure RLS is turned on for those, too. A table without RLS can be read and changed by anyone.

How do I review the policies on one table? Click the database icon, open the table, then click View policies to review the row-level security policies applied to it. To make updates, ask Bolt for help or check the Security Audit tab for automatic fixes.

What if I'm not sure my tables are protected? Ask Bolt in the chat, for example: Check that row-level security is on for every table in my database, and that each policy allows only the access my site needs.

Related guides

• Data won't save: 'new row violates row-level security policy' covers the same error on other tables and forms.
• Users can see other users' data in my Lovable app: find it and lock it down explains how to tighten policies that are too open.
• How to test your AI-built app like a real customer (the live app, not the preview) shows how to run the check above properly.

Sources

• Database security settings - Bolt
• Database tables - Bolt
• Database authentication settings - Bolt
• Row Level Security - Supabase Docs

VibeFix's AI agent signs up to your live app like a new person and shows whether sign-up and your pages work. It may not show visitor form insert blocked by RLS in Bolt directly. VibeFix checks; it does not fix your app.

Last checked: 18 October 2026, against the sources listed above.

VibeFix is independent. Lovable, Bolt, Replit, Base44, v0 and Supabase are trademarks of their owners.