new row violates row-level security policy

Supabase ha rechazado guardar una fila. La tabla tiene activada la seguridad por filas, que es lo correcto, pero no hay ninguna regla que diga quién puede escribir en ella. Cuando no hay regla, la respuesta por defecto es que no.

Ya de paso: ¿tu app está exponiendo datos?

Analízala gratis mientras lees. Tarda treinta segundos y no toca nada.

Solo leemos lo que tu app ya le entrega a cualquier visitante.

Por qué te pasa

La seguridad por filas de Supabase funciona al revés de lo que uno espera: no bloquea lo que le dices que bloquee, sino que bloquea todo salvo lo que autorizas explícitamente. Al activarla en una tabla, esa tabla se cierra entera hasta que escribes una política que abra una rendija concreta.

Es muy habitual haber escrito la política de lectura y haberse olvidado de la de escritura. Se prueba la app, se ve que los datos se muestran bien, y el problema no aparece hasta que alguien intenta guardar algo. También pasa cuando la política existe pero exige que el usuario esté identificado y quien escribe no lo está, o cuando exige que el campo de propietario coincida con el usuario y tu código no está rellenando ese campo.

Lo que este error no significa

No es un fallo de seguridad, es exactamente lo contrario. Tu base de datos está haciendo su trabajo: rechazar una escritura que nadie ha autorizado. Preferimos verte este error a verte la tabla abierta de par en par.
No has perdido los datos que ya tenías. La operación se ha rechazado entera; no se ha guardado nada a medias ni se ha corrompido ninguna fila.
No hace falta desactivar la seguridad por filas para arreglarlo, y desactivarla es la peor cosa que puedes hacer. Deja tu tabla legible y modificable por cualquiera que visite tu web, y ese sí sería un problema de verdad.

Arréglalo tú, gratis

Esto se arregla en el panel de Supabase, en menos de cinco minutos. Ve con una idea clara de quién debe poder escribir en esa tabla antes de empezar, porque es la única decisión que importa aquí.

1Entra en tu proyecto de Supabase y ve a Authentication y luego Policies. Busca la tabla que da el error.
2Mira qué políticas tiene. Si solo ves una de tipo SELECT, ese es el problema: tienes permiso de lectura pero ninguno de escritura.
3Pulsa en crear una política nueva para esa tabla y elige la operación INSERT.
4Elige quién puede escribir. Si solo deben poder hacerlo usuarios que han iniciado sesión, la condición es auth.role() = 'authenticated'. Si además cada usuario solo debe poder crear filas suyas, la condición compara el campo de propietario de la tabla con auth.uid(), y tu código tiene que estar rellenando ese campo al guardar.
5Guarda y prueba de nuevo desde la app. Si necesitas también editar o borrar, repite el proceso con UPDATE y DELETE: cada operación necesita su propia política.

Si en algún momento ves un ejemplo que sugiere poner la condición a true para todo el mundo, eso equivale a dejar la tabla abierta. Solo tiene sentido en tablas de contenido público, nunca en una con datos de clientes.

Y esto para la parte de código

Pégaselo tal cual al agente que escribió tu app. Está redactado para que te diga lo que ha hecho, no solo para que lo haga.

Prompt para pegarle a tu agente

Mi app da el error "new row violates row-level security policy" al intentar guardar en Supabase.

Necesito que hagas esto:
1. Busca en el código la operación de inserción que está fallando y dime en qué tabla escribe y qué campos envía.
2. Comprueba si esa tabla tiene un campo de propietario (del tipo user_id) y si el código lo está rellenando con el identificador del usuario que ha iniciado sesión. Si no lo rellena, corrígelo.
3. Comprueba que la operación se hace con el usuario identificado y no con una sesión anónima, y dime en qué punto del código se establece esa sesión.
4. Escríbeme la política de RLS que necesita esa tabla en SQL, para que yo la revise antes de aplicarla en el panel de Supabase, y explícame en una línea a quién deja escribir.

Muy importante: no desactives RLS ni escribas una política que permita escribir a cualquiera, y no uses la clave service_role en el código del navegador bajo ningún concepto.

¿Lo has intentado y sigue sin salir?

O el escáner de arriba ha encontrado algo y prefieres no tocarlo solo. En cualquiera de los dos casos esto ya es de los gordos y merece un humano: no es que no hayas sabido, es que has llegado al punto en que hace falta alguien que entre y lo vea por dentro.

Cita a partir de mañana

Agendar revisión

99 €

Elegimos hueco, miro tu app con calma y te digo qué pasa y cómo se arregla.

Sesión de trabajo en directo contigo
Diagnóstico del error y del riesgo real
Te quedas con el arreglo aplicado

Ver huecos disponibles

Hoy, en cola prioritaria

Rescate exprés

199 €

Entras en la cola de hoy. Reservas hueco y lo dejamos resuelto en el día.

Hueco el mismo día
Prioridad sobre las revisiones agendadas
Mismo trabajo, antes

Ver huecos de hoy

Quién lo arregla

Marc Sala

IT Manager

Analista de ciberseguridad certificado por Google

No es un rating anónimo de un marketplace: es la persona que va a entrar en tu app. Reviso el código, encuentro qué falla y lo arreglo contigo delante.