Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Un empleado no desarrollador crea una aplicación web sorprendente en solo tres días usando herramientas de "vibe coding" como v0 o Cursor. El CEO, entusiasmado, propone conectarla de inmediato a la base de datos de producción para que los clientes comiencen a usarla. En ese momento, los desarrolladores o el CTO empiezan a sudar frío. Al revisar el código generado por la IA, descubren que la cadena de conexión a la base de datos (DSN) está incrustada directamente en pleno componente del cliente, o que se están ejecutando consultas SQL sin ningún tipo de validación.
Subir esto tal cual al servidor de producción es una receta para el desastre. El informe OWASP Top 10 for LLM Applications 2025 señala la concesión excesiva de permisos en el código generado por IA (LLM06) y la falta de validación de entradas (LLM05) como los riesgos de seguridad más críticos. De hecho, el 73% de los incidentes de vulneración de seguridad en aplicaciones web se aprovechan precisamente de la ausencia de validación de entradas.
Para proteger la base de datos de la empresa sin frenar la productividad de los empleados no desarrolladores, es necesario establecer una capa de control sólida entre el prototipo y la base de datos.
Lo primero que se debe hacer es bloquear el camino para que la aplicación creada por el no desarrollador no pueda llamar directamente a la base de datos. Se debe colocar un Route Handler de Next.js App Router en el servidor como proxy y validar en tiempo real los datos entrantes mediante la librería Zod. La verificación de tipos de TypeScript solo funciona durante el desarrollo; no evita que el servidor falle cuando un usuario real envía datos maliciosos o inesperados.
| Elemento de validación | Validación en la UI del navegador | Capa proxy con Zod en el servidor |
|---|---|---|
| Ubicación de ejecución | Navegador del cliente | Tiempo de ejecución serverless de Vercel |
| Nivel de seguridad | Fácil de eludir con herramientas de desarrollo | Bloqueo forzado en el servidor para proteger la DB |
| Validación de datos | Verificación superficial de texto | Validación precisa de tipos y rangos de valores en tiempo de ejecución |
| Manejo de errores | Muestra un mensaje de advertencia en pantalla | Devuelve HTTP 400 y registra el error en Sentry |
El proceso de configuración es sencillo:
app/api/v1/customer-records/route.ts en tu proyecto.companyName tenga al menos 2 caracteres, contactEmail cumpla con el formato de correo electrónico y employeeCount acepte solo enteros positivos.request.json() usando schema.parse(). Solo los datos que aprueben la validación se insertan en la base de datos a través del ORM Prisma; si la validación falla, se rechaza la solicitud en el acto devolviendo un error 400.Junto con la validación a nivel de aplicación, también se debe aplicar una capa de defensa en la propia base de datos. Si utilizas Supabase basado en PostgreSQL, la respuesta es configurar Row Level Security (RLS). Guarda la información sobre el rol del usuario en raw_app_meta_data (gestionado exclusivamente por administradores) en lugar de raw_user_meta_data (modificable por el usuario) y valida el JWT.
`sql
-- 1. Habilitar RLS en la tabla
ALTER TABLE public.enterprise_documents ENABLE ROW LEVEL SECURITY;
-- 2. Crear función para extraer el rol del usuario desde el JWT
CREATE OR REPLACE FUNCTION get_user_role()
RETURNS text AS
LANGUAGE sql STABLE;
-- 3. Política que permite el acceso solo a administradores o a miembros del mismo departamento
CREATE POLICY "Department Access Policy" ON public.enterprise_documents
FOR SELECT USING (
get_user_role() = 'admin' OR
department = (current_setting('request.jwt.claims', true)::json->'app_metadata'->>'department')
);
`
Con esta configuración, incluso si un no desarrollador filtra accidentalmente la clave de rol de servicio (Service Role Key) en el código, los documentos confidenciales de otros departamentos nunca quedarán expuestos.
Las herramientas de IA están diseñadas principalmente para hacer funcionar la interfaz visual, por lo que suelen colocar claves API o cadenas de conexión a la base de datos en lugares expuestos al navegador. El error más común es añadir el prefijo NEXT_PUBLIC_ sin criterio. En Next.js, cualquier variable con este prefijo se incluye en texto plano dentro de los archivos JavaScript del navegador. En el momento en que creas una variable como NEXT_PUBLIC_OPENAI_API_KEY, cualquiera que sepa abrir las herramientas de desarrollo (F12) puede tomar tu clave API y usarla libremente.
Un buen ejemplo es el incidente de seguridad ocurrido en la infraestructura de Vercel en abril de 2026. Al vulnerarse los permisos de una herramienta de IA de terceros integrada, las variables de entorno no ocultas quedaron expuestas, obligando a numerosos equipos a pasar la noche en blanco regenerando claves API y contraseñas de bases de datos una por una.
Es imposible que un ser humano revise todos estos errores de forma manual. Se debe integrar la herramienta de análisis estático Gitleaks en GitHub Actions para detectar y eliminar automáticamente estas filtraciones antes de fusionar el código.
`yaml
name: Security Scan
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
gitleaks-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Install and Run Gitleaks
run: |
wget https://github.com/gitleaks/gitleaks/releases/download/v8.18.0/gitleaks_8.18.0_linux_x64.tar.gz
tar -xzvf gitleaks_8.18.0_linux_x64.tar.gz
sudo mv gitleaks /usr/local/bin/
gitleaks detect --source=. --verbose --redact --exit-code=1
public-env-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check Unsafe Public Keys
run: |
UNSAFE=(grep -rn "NEXT_PUBLIC_.*\(SECRET\|KEY\|PASSWORD\|TOKEN\|DSN\)" . || true)
if [ -n "UNSAFE" ]; then
echo "Variables sensibles expuestas en el cliente detectadas:"
echo "$UNSAFE"
exit 1
fi
`
Al configurar esta canalización, en el momento en que un usuario no desarrollador intente hacer un Push incluyendo una clave API en el código fuente o en una variable NEXT_PUBLIC_, el despliegue se bloqueará de forma automática.
Incluso al registrar variables en el panel de Vercel, se deben separar claramente los entornos de Development, Preview y Production. En particular, asegúrate de activar la casilla Sensitive Environment Variable. De este modo, las variables no se mostrarán en los registros de compilación ni se podrán copiar en texto plano desde el panel de control.
Si los servidores de OpenAI o Anthropic dejan de responder o sufren retrasos, todos los manejadores serverless entran en estado de espera, provocando un fallo en cadena. En estos casos, se debe implementar un patrón circuit breaker utilizando la librería opossum de Node.js.
`typescript
import CircuitBreaker from 'opossum';
async function callLLM(prompt: string) {
// Lógica de llamada a la API de LLM
}
const options = {
timeout: 5000, // Se considera fallo si excede los 5 segundos
errorThresholdPercentage: 50, // Abre el circuito si la tasa de fallos supera el 50%
resetTimeout: 30000 // Reintenta después de 30 segundos
};
const breaker = new CircuitBreaker(callLLM, options);
breaker.fallback(() => ({ error: "La respuesta de la IA se está retrasando. Por favor, inténtelo de nuevo más tarde." }));
`
Si la respuesta de la API se retrasa, enviar un mensaje informativo predefinido en 0,1 segundos evita que todo el servicio quede fuera de servicio.
También es recomendable conectar Sentry con webhooks de Slack para que el creador no desarrollador pueda enterarse inmediatamente de la situación de fallo.
`typescript
// app/api/webhooks/sentry-to-slack/route.ts
import { NextResponse } from 'next/server';
export async function POST(request: Request) {
try {
const event = await request.json();
const webhookUrl = process.env.SLACK_INCOMING_WEBHOOK_URL;
if (!webhookUrl) return NextResponse.json({ error: 'Sin Webhook' }, { status: 500 });
const title = event.data?.issue?.title || 'Error desconocido del sistema';
const issueUrl = event.data?.issue?.permalink || '#';
await fetch(webhookUrl, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
blocks: [
{
type: 'header',
text: { type: 'plain_text', text: '🚨 Error en producción' }
},
{
type: 'section',
text: { type: 'mrkdwn', text: `*Detalle del error:*
${title}` }
},
{
type: 'actions',
elements: [
{
type: 'button',
text: { type: 'plain_text', text: 'Ver informe en Sentry' },
url: issueUrl,
style: 'danger'
}
]
}
]
})
});
return NextResponse.json({ success: true });
} catch (err) {
return NextResponse.json({ error: 'Error en Webhook' }, { status: 500 });
}
}
`
Si el problema escala a un fallo de nivel P1 donde la página principal deja de cargar, ni siquiera hace falta esperar a un desarrollador. Vercel conserva intactas las implementaciones anteriores, por lo que es posible regresar al estado previo con solo unos clics.
Basta con esperar 30 segundos para que el enrutamiento del dominio cambie a la versión anterior. Al contar con validación con Zod, escaneo con Gitleaks y procedimientos de rollback en Vercel, puedes permitir que los empleados no desarrolladores creen aplicaciones libremente mientras duermes con total tranquilidad.