Escaneo de seguridad antes del despliegue en aplicaciones web

Curso Gratis de Lovable para Crear Páginas Web sin Programar

Contenido del curso

Fundamentals and MVP Planning

Visual Construction of the Front-end

Data, Users and Business Logic

Launch, Testing and Feedback

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:18

Escaneo de seguridad antes del despliegue en aplicaciones web

Curso Gratis de Lovable para Crear Páginas Web sin Programar

Clase 17 de 20

Clase 17 / 20

Comentarios (14)14 comentarios

Beder Danilo Casa Condori

Hace un año

El escaneo de seguridad antes del despliegue en aplicaciones web es crucial para identificar vulnerabilidades que podrían exponer datos sensibles. Durante esta fase, se utilizan herramientas como el escáner de seguridad de Lovable, que analiza la base de código y las configuraciones de seguridad. Detecta problemas como accesos no autorizados a datos personales y sugiere arreglos, como implementar políticas de seguridad robustas y asegurarse de que los usuarios autenticados tengan acceso adecuado. Esto ayuda a prevenir brechas de seguridad antes de que la aplicación sea lanzada al público.

MARIA TERESA PANIAGUA RIVERA

Hace 9 meses

Thanks

Juliana Carranza

Hace 10 meses

No conocía sobre Have I Been Pwned, es una muy buena defensa de seguridad cuando hay una tendencia a reutilizar contraseñas, haciendo que Lovable rechace las contraseñas que han sido comprometidas, haciendo que Supabase la rechace de inmediato. Algo "injusto" para los que preferimos contraseñas sencillas para casi todos, pero necesario para preservar nuestra seguridad. 😅

Lautaro Agustin Barrera

Hace 8 meses

El Prevent use of leaked passwords solo está disponible para la versión pro de SupaBase (25usd por mes).

Gabriel Obregón

Hace 9 meses

🛡️ SECURITY

🚀 Lovable + Supabase (Pre-Deploy)

🎯 OBJECTIVE

🔐 Deploy applications without exposing sensitive data, applying security controls before publishing.

✔ Detect risks

✔ Fix insecure configurations

✔ Strengthen authentication

✔ Publish with confidence

⚠️ WHY IS SECURITY CRITICAL?

A small mistake can leave data visible on the Internet 🌐

🔴 Common risks

📂 Public tables → exposed emails / IPs
🔓 Lack of access control
🗝️ Misconfigured keys or policies

🟢 Prevention

Run Review Security
Fix EVERYTHING before deploy

🚫 MISTAKES YOU MUST AVOID

❌ “Rogue” tables open to everyone

❌ Policies that allow viewing emails

❌ Publishing without reading the report

❌ Ignoring pre-deployment warnings

👉 Rule: if there are alerts, do not publish

🔍 KEY TOOL — Review Security

🧪 Automatic security scan across:

🧩 Code

🗄️ Supabase (tables and policies)

🔐 Authentication and authorization

🧠 What does it detect?

⚠️ High and medium risks

📤 Exposure of personal data

🔓 Weak access policies

🛠️ What does it offer?

🔧 Try Fix (automatic fixes)

📄 Clear, actionable report

✅ Confirmation of improvements

🎯 Ability to reach 0 issues

🛠️ ACTIONS FROM THE REPORT

✔ Remove public reads of sensitive data

✔ Require login to access data

✔ Apply suggested fixes

✔ Re-run the scan

📋 Use the report as a checklist

🚀 PUBLISH WITH ZERO ISSUES

🔁 Recommended flow:

1️⃣ Run the scan

2️⃣ Review errors

3️⃣ Apply Try Fix

4️⃣ Re-scan

5️⃣ Implement security fixes

6️⃣ Confirm 0 errors

7️⃣ Publish ✅

🧱 SUPABASE — BEST PRACTICES

⚙️ Security is defined through SQL policies

🔐 Core principles

🔑 Authentication required
🚫 No public access to sensitive data
👤 Each user sees only their own data

🧍‍♂️ ROW-LEVEL SECURITY (RLS)

🛡️ Controls access per user

✔ Create

✔ Read

✔ Update

✔ Delete

📌 Only own data

⚠️ Important:

May change app behavior
Always test critical flows

🔑 EXTRA LAYER — LEAKED PASSWORDS

🧠 Supabase can block compromised passwords

🔍 Checks against public breach databases

🌐 e.g. Have I Been Pwned

🚫 Blocks insecure logins

✅ Simple and effective defense

🛡️ Reduces account takeover

Yaritza Jazmin Sanchez Rosa

Hace 4 meses

¿Qué pasa si usan contraseñas ya filtradas?

Los atacantes podrían secuestrar cuentas usando ataques de fuerza bruta o relleno de credenciales. Muchas personas reutilizan la misma contraseña en múltiples sitios web. Si uno de esos sitios sufre una brecha de seguridad, los hackers publican esas credenciales en foros oscuros. Si tu aplicación permite que un usuario se registre con una de estas contraseñas comprometidas, estás dejando la puerta abierta para que scripts automatizados prueben esas combinaciones y tomen control de las cuentas de tus clientes. Para mitigar esto, puedes integrar servicios de validación que consultan bases de datos globales de brechas de seguridad (como Have I Been Pwned). Al activar esta protección, tu sistema de autenticación rechazará automáticamente cualquier clave que ya sea pública en internet, obligando al usuario a elegir una credencial verdaderamente segura. Es una configuración sencilla que eleva drásticamente el nivel de seguridad de tu plataforma sin requerir código complejo.

Yaritza Jazmin Sanchez Rosa

Hace 4 meses

¿Es posible automatizar las correcciones de seguridad?

Sí, muchas herramientas modernas de desarrollo asistido por IA pueden aplicar parches automáticamente. Hoy en día, no necesitas ser un experto en ciberseguridad para resolver vulnerabilidades comunes. Cuando un escáner detecta un problema, como una tabla sin políticas de acceso o una configuración de autenticación débil, los asistentes de inteligencia artificial integrados pueden generar y ejecutar el código necesario para cerrarla. Por ejemplo, si el sistema nota que una tabla de lista de espera expone direcciones IP, la IA puede escribir la regla SQL exacta para restringir la lectura solo a administradores. Al aceptar la sugerencia, el parche se implementa en segundos. Sin embargo, es vital que revises qué cambios se están aplicando. Automatizar la corrección es fantástico para la velocidad, pero siempre debes entender cómo afecta la lógica de tu aplicación para evitar que funciones legítimas se rompan por reglas demasiado estrictas.

Rodrigo Ramírez

Hace 7 meses

Tengo una pregunta relacionada con un comentario que vi en lecciones anteriores sobre hacer el repositorio en GitHub y continuar en Cursor con Claude Code, la pregunta es ¿Se puede implementar completamente este proceso desde Cursor? o es más exclusivo de Lovable, pregunto desde una total oscuridad XD

Andres David Martinez Torres

Hace 8 meses

Para ser una revision de primer y segundo nivel es muy buena y puede ser un punto de partida

Leyder Sanchez

Hace 10 meses•editado

🫥

Gerson Antonio Cabrera

Hace un año•editado

La seguridad es fundamental en el despliegue de cualquier aplicación; ignórala, y tus datos estarán en riesgo, como se explica en la clase.

Fredy Pico

Hace un año

But is it necessary to have the warning message?

Follow me:

EDGAR LÓPEZ FIERRO

Hace un año

Habilitar la protección con contraseña 'Have I Been Pwned' en Supabase permite a los desarrolladores verificar si las contraseñas de los usuarios han sido comprometidas en filtraciones de datos. Esto evita que se permitan contraseñas inseguras, aumentando la seguridad de las cuentas. Así, se protege a los usuarios de posibles accesos no autorizados, mejorando la integridad de la aplicación y la confianza en el manejo de datos sensibles. Implementar esta función es un paso proactivo para fortalecer la seguridad en el desarrollo de aplicaciones.

EDGAR LÓPEZ FIERRO

Hace un año

Las políticas SQL son reglas que definen el acceso a los datos en una base de datos, especialmente en sistemas que utilizan Row Level Security (RLS). Estas políticas determinan quién puede ver o modificar registros específicos basándose en atributos del usuario, como su rol o estado de autenticación. En el contexto de la clase, es crucial asegurarse de que la exposición de datos sensibles, como correos electrónicos, esté restringida mediante estas políticas para mantener la seguridad de la aplicación.

Recursos

Protecting user data is non-negotiable when deploying with Lovable and Supabase. Here you’ll find a clear path to spot exposure risks, use the built-in security review, tighten policies with SQL and row-level security, and add an extra layer with leaked password protection. Follow these steps to ship with confidence and avoid public data leaks.

Why does security matter before deployment?

Leaving a table open or skipping an access key can expose customer data to the internet. Before publishing, use Lovable’s Review Security to detect misconfigurations and block risky releases.

Public tables can leak emails or IP addresses.
Missing access control invites unauthorized reads and writes.
The security scan flags errors before you click publish.
Fix issues first, then deploy.

What common pitfalls should you avoid?

Creating “rogue” tables open to everyone.
Allowing policies that let anyone view emails.
Publishing without reading the security report.
Ignoring warnings marked before deployment.

How does Lovable’s security review tool help?

The Review Security button runs a full security scan across code, Supabase tables, and authorization. It surfaces high and medium risks, offers a clear report, and lets you apply fixes automatically with Try Fix or implement security fixes.

It scans your whole codebase and Supabase configuration.
It highlights data exposure (for example, a wait list table with personal emails or IPs).
It suggests strengthening authentication where needed.
It confirms improvements and can reach zero issues before publish.

What actions can you take from the report?

Drop unsafe policies that allow public reads of sensitive fields.
Require users to be signed in before accessing data.
Apply suggested fixes, then re-run the scan to verify.
Use the report as a checklist to close any gaps.

How do you publish safely with zero issues?

Run the scan, review errors, and click Try Fix if available.
Refresh and re-check the scanner until issues are cleared.
Apply the implement security fixes flow when you agree with changes.
Confirm zero errors, then proceed to publish.

What Supabase and RLS practices should you apply?

Security changes often involve SQL policies in Supabase. Removing a policy that lets anyone view emails and adding rules that require authenticated access are essential. Row-level security (RLS) ensures signed-in users can create, read, update, and delete only their own data—without touching others’. Fixes may affect app behavior, so validate queries and permissions after changes.

Enforce authentication before reading or writing sensitive data.
Use RLS so each user only accesses their records.
Review and adjust policies to match your data model.
Test critical flows after policy updates.

How can you strengthen authentication with leaked password checks?

Enable Supabase’s protection against known leaked passwords. It checks credentials against data exposed on sites like Have I Been Pwned and blocks logins using compromised passwords. It’s a small switch that adds a strong defense against account takeovers.

Have questions or tips on RLS, security scans, or password protection? Share your experience and what worked for you.

Resumen

Why does security matter before deployment?

Public tables can leak emails or IP addresses.
Missing access control invites unauthorized reads and writes.
The security scan flags errors before you click publish.
Fix issues first, then deploy.

What common pitfalls should you avoid?

Creating “rogue” tables open to everyone.
Allowing policies that let anyone view emails.
Publishing without reading the security report.
Ignoring warnings marked before deployment.

How does Lovable’s security review tool help?

It scans your whole codebase and Supabase configuration.
It highlights data exposure (for example, a wait list table with personal emails or IPs).
It suggests strengthening authentication where needed.
It confirms improvements and can reach zero issues before publish.

What actions can you take from the report?

Drop unsafe policies that allow public reads of sensitive fields.
Require users to be signed in before accessing data.
Apply suggested fixes, then re-run the scan to verify.
Use the report as a checklist to close any gaps.

How do you publish safely with zero issues?

Run the scan, review errors, and click Try Fix if available.
Refresh and re-check the scanner until issues are cleared.
Apply the implement security fixes flow when you agree with changes.
Confirm zero errors, then proceed to publish.

What Supabase and RLS practices should you apply?

Enforce authentication before reading or writing sensitive data.
Use RLS so each user only accesses their records.
Review and adjust policies to match your data model.
Test critical flows after policy updates.

How can you strengthen authentication with leaked password checks?

Have questions or tips on RLS, security scans, or password protection? Share your experience and what worked for you.

Fundamentals and MVP Planning

Crea apps sin código con Lovable

Creación de un proyecto en blanco y efectos animados con p5.js

Chat y Edit mode en Lovable

Knowledge files para apps consistentes en Lovable

User stories y diagramas para MVPs rápidos

Diseña el style guide de tu app en Lovable

Visual Construction of the Front-end

Refactoriza componentes grandes en Lovable

Personaliza tu UI con componentes de 21stDev

Rutas en React Router con Lovable

Prompting en español con comentarios en inglés en Lovable

Cómo conectar Supabase a Lovable

Data, Users and Business Logic

CRUD básico con Lovable y Supabase para crear tablas de datos

Cómo conectar una API externa con Lovable

Formularios de feedback y waitlist con Lovable

Cómo crear un flujo de onboarding con Supabase

Cómo depurar errores en Lovable

Launch, Testing and Feedback

Escaneo de seguridad antes del despliegue en aplicaciones web

Cómo publicar tu app y conseguir tus primeros usuarios

Conectar un dominio personalizado en Lovable

Cómo gestionar y priorizar feedback en Lovable

Escaneo de seguridad antes del despliegue en aplicaciones web

Progreso del curso

Fundamentals and MVP Planning

Visual Construction of the Front-end

Data, Users and Business Logic

Launch, Testing and Feedback

Recursos

Recursos