¿Vercel es seguro? Brecha de abril 2026 y variables de entorno

Infraestructura

Vercel ofrece HTTPS automático, CDN global con protección contra DDoS y variables de entorno cifradas. La seguridad de la aplicación sigue siendo tuya: Edge Functions, middleware, env vars e integraciones OAuth. Ahí ocurrió el incidente de Context.ai de abril de 2026.

Consideraciones de seguridad

Funciones serverless

Las funciones Edge y serverless pueden exponer vulnerabilidades de API. Fallos frecuentes:

• Sin rate limit: una URL filtrada de un proxy a OpenAI genera costos por hora.
• Sin validación de input, por ejemplo un eval sobre input de usuario.
• Lógica de auth que solo cubre el caso feliz y en el negativo continúa con next() en vez de devolver 401.

// middleware.ts: chequeo de auth mínimo que sí rechaza
import { NextResponse } from "next/server";

export function middleware(req: Request) {
  const token = req.headers.get("authorization");
  if (!token || !verifyJwt(token)) {
    return new NextResponse("Unauthorized", { status: 401 });
  }
  return NextResponse.next();
}

export const config = { matcher: ["/api/:path*"] };

Variables de entorno

Los deploys de preview no deberían tener credenciales de producción. El incidente de abril de 2026 con la app OAuth de Context.ai expuso variables de entorno no marcadas como “sensibles” en algunos clientes de Vercel, incluyendo claves de API y credenciales de BD.

Tres reglas:

1. Usa el flag Sensitive. En Vercel, Los valores Sensitive desaparecen de logs, lecturas de dashboard y scopes OAuth. Aplícalo a cada secreto.
2. Separa credenciales de preview. Una BD sandbox aparte, una clave de Stripe Test aparte. Si la rama de preview filtra, el daño queda acotado.
3. Prohíbe vercel env pull en CI. El comando escribe todas las env vars en texto plano en un archivo .env local, que puede acabar en artefactos de CI.

Deploys de preview

Los deploys de preview son públicos por default. En cualquier proyecto con APIs reales o flujos de auth reales, activa Deployment Protection: Standard para reviews internos, SSO para equipos con IdP, o Password Protection para stakeholders externos.

Código de la aplicación

XSS, problemas de autenticación y vulnerabilidades de API son responsabilidad tuya. Configura los headers de seguridad una vez en vercel.json, en lugar de ruta por ruta:

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Strict-Transport-Security", "value": "max-age=63072000; includeSubDomains; preload" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Content-Security-Policy", "value": "default-src 'self'; script-src 'self'" }
      ]
    }
  ]
}

Edge Middleware

El middleware corre en el edge antes de cada ruta, y un refactor puede desactivarlo sin que lo notes. Define los paths del matcher explícitamente en lugar de usar wildcards, y escribe un test por middleware que verifique 401 ante una request no autenticada.

Integraciones OAuth en el dashboard

Apps OAuth de terceros (bots de Slack, CI/CD, observabilidad) pueden vincularse a tu cuenta, y su scope por default suele ser más amplio de lo necesario. Revisa Account Settings → Integrations cada trimestre y revoca lo que no uses.

Evaluación de seguridad

Puntos fuertes

• • HTTPS y protección DDoS en la infraestructura
• • TLS 1.3 automático
• • Conformidad SOC 2 Type II
• • Variables de entorno cifradas
• • Controles de acceso en deploys de preview

Preocupaciones

• • La seguridad de la aplicación es responsabilidad del desarrollador
• • Las funciones serverless pueden exponer vulnerabilidades
• • Las variables de entorno necesitan scope adecuado
• • Los deploys de preview pueden exponer features sensibles
• • Las apps OAuth de terceros (como el incidente Context.ai de abril/2026) pueden acceder a env vars no marcadas como sensibles

Aspectos enterprise

En los planes Pro y Enterprise, Vercel ofrece funciones relevantes para entornos regulados:

• SSO vía SAML. En Enterprise, Vercel fuerza SSO para todos los miembros del team. Es la respuesta a “¿quién tiene acceso al dashboard de deployments?”.
• Audit logs. Cada acción del dashboard (deployment, edición de env var, cambio de dominio) queda logueada. Stream a S3, Datadog o Splunk. Sin copia externa, en un incidente solo ves lo que muestra el UI de Vercel.
• Frontera SOC 2. Vercel cumple SOC 2 Type II, pero la conformidad aplica a operaciones de la plataforma. Tu código, tus env vars y tus apps OAuth quedan fuera de esa frontera.
• Secure Compute. En Enterprise hay workers dedicados de build y runtime, allowlists de IP de salida y Vercel Functions privadas. Útil para workloads regulados, pero no reemplaza la seguridad de la app.

El veredicto

Vercel es una plataforma segura para producción: cumple SOC 2 Type II y activa HTTPS y protección DDoS por default. Centra tu esfuerzo en el código de tu aplicación, los endpoints de la API, las variables de entorno y las apps OAuth con acceso a tu dashboard.

Tres chequeos antes de cada lanzamiento:

1. Cada env var que no debe llegar al navegador está marcada como Sensitive.
2. Deployment Protection está activo en Preview.
3. Cada app OAuth bajo Integrations se sigue usando o está revocada.

Recursos relacionados

Cómo proteger Vercel

Guía paso a paso de seguridad: scoping de env vars, patrones de middleware, configuración de headers, auditoría de OAuth.

Checklist de seguridad de Vercel

Checklist de seguridad interactiva pre-lanzamiento.

Token Leak Checker

Encuentra claves de API y secretos filtrados en tu bundle de frontend o en logs de build.

Auditoría de Edge Functions

Revisa cada Edge y Serverless Function en busca de auth ausente, falta de rate limit y validación de input.

Riesgos de seguridad de vibe coding

Resumen de los patrones de fallo que el código generado por IA introduce típicamente en apps deployadas en Vercel.

Escanea tu app Vercel

VibeEval escanea tu deploy en Vercel: env vars filtradas en el bundle, URLs de preview desprotegidas, agujeros de auth en API routes y headers de seguridad ausentes.