Seguridad de APIs para Startups SaaS: Checklist por Fases (2026)

Eres el único backend developer de una startup SaaS de gestión de proyectos. Tu API tiene 60 endpoints, dos roles (member y owner de workspace), y un release semanal a producción. La semana pasada un cliente preguntó por tu "modelo de seguridad de APIs" antes de firmar la renovación anual. Tu respuesta honesta sería que el modelo es "intentamos no romper nada y rezar". La respuesta que tienes que dar es otra.

El problema no es que falte información sobre seguridad de APIs — sobra. El problema es que casi toda está escrita asumiendo equipos de seguridad dedicados, presupuestos de cinco cifras y procesos de revisión que duran semanas. Si eres una startup de pre-seed con dos backend devs, ese consejo no te sirve. Necesitas saber qué hacer esta semana, qué puede esperar a la Serie A y qué solo importa cuando ya tengas 50 ingenieros.

Esta es la guía que ordena ese caos. Catorce puntos agrupados en tres fases por etapa de financiación. Cada uno respeta la realidad de equipos pequeños: nada que requiera contratar a un CISO, comprar una herramienta de cinco cifras o detener releases para hacer auditorías de un mes. Si quieres profundizar en los riesgos específicos de cada categoría, la guía de seguridad API REST cubre el "por qué" — esta cubre el "qué hago el lunes".

Cómo usar este checklist

Tres reglas antes de empezar:

1. No hagas saltos de fase. Implementar autenticación mutua TLS antes de tener rate limiting básico es como poner una puerta blindada en una casa sin tejado. Las fases están ordenadas por relación impacto/esfuerzo para tu etapa.
2. Cada item es ejecutable por una persona en menos de un día. Si un item te lleva una semana, lo estás sobre-ingenierizando. Vuelve al alcance mínimo y descarta el resto.
3. El objetivo de la Fase 1 no es "estar seguro". Es "no aparecer en los titulares por algo trivial". La seguridad real se construye fase a fase.

Fase 1 — Pre-seed / Seed (1-2 backend devs, MVP en producción)

El objetivo aquí es eliminar las clases enteras de vulnerabilidades que un atacante automatizado encuentra sin esfuerzo. No hablamos de hardening avanzado. Hablamos de cerrar las puertas que están abiertas de par en par.

1. HTTPS forzado en toda la API, sin excepciones

No "HTTPS en producción y HTTP en staging". HTTPS en todo: producción, staging, entornos de demo, sandboxes para clientes. Cualquier endpoint que responda en HTTP es un endpoint donde un atacante en la misma red puede leer tokens, sesiones y payloads completos.

Configuración mínima en tu proxy/load balancer:

1# nginx — redirige todo HTTP a HTTPS y aplica HSTS
2server {
3listen 80;
4server_name api.tuapp.com;
5return 301 https://$host$request_uri;
6}
7
8server {
9listen 443 ssl http2;
10server_name api.tuapp.com;
11
12add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
13# ... resto de la config
14}

Verifica que se aplica:

curl -I https://api.tuapp.com/health | grep -i strict-transport

Si no aparece Strict-Transport-Security, no está activo.

2. Autenticación con tokens de corta duración

Si emites JWT que duran 30 días, has emitido bombas de relojería. Cualquier token filtrado en un log, en un screenshot de soporte, en un repo público que un dev empujó por error, es válido durante un mes.

Configuración mínima:

• Access token: 15-30 minutos de vida.
• Refresh token: rota en cada uso (one-time use). Si el cliente intenta usar un refresh token ya consumido, invalida toda la familia de tokens — es señal de robo.
• Algoritmo: RS256 o EdDSA, nunca HS256 con un secreto débil. Si usas HS256, el secreto debe tener al menos 256 bits de entropía real (openssl rand -base64 32).

3. Una comprobación de autorización por endpoint, en la query

El error de seguridad más común en APIs SaaS es separar "obtener el recurso" de "verificar que el usuario puede verlo". La forma robusta es hacerlo en una sola query que ya incluya la condición de pertenencia (workspaceId, tenantId o el discriminador que uses), siguiendo el patrón de autorización en la query que cubrimos en la guía de BOLA.

const task = await db.tasks.findOne({ id: req.params.taskId, workspaceId: req.user.workspaceId });
if (!task) return res.status(404).end();

Devolver 404 en lugar de 403 evita filtrar la existencia del recurso.

4. Validación de entrada con esquema, rechazo estricto

Define un esquema para cada endpoint con Zod, Pydantic o el equivalente de tu stack. Rechaza cualquier campo no declarado. Esto previene mass assignment (un atacante envía "role": "owner" en el body de un PUT a su propio perfil) y reduce la superficie de inyecciones.

const updateTaskSchema = z.object({
  title: z.string().min(1).max(200),
  status: z.enum(["todo", "in_progress", "done"]),
  assigneeId: z.string().uuid().optional(),
}).strict(); // .strict() rechaza cualquier campo extra

El .strict() es la línea que separa "tengo validación" de "tengo validación útil".

5. Rate limiting al menos en endpoints sensibles

No necesitas rate limiting global perfecto desde el día uno. Necesitas rate limiting en los tres endpoints que importan: login, registro y reset de contraseña. Sin esto, un atacante hace credential stuffing con credenciales filtradas de otras brechas hasta que entre en una cuenta.

Configuración mínima con express-rate-limit o el equivalente:

import rateLimit from "express-rate-limit";

app.post("/auth/login", rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutos
  max: 5,                   // 5 intentos por IP
  standardHeaders: true,
}), loginHandler);

Esto no para a un atacante con botnet distribuida, pero sí elimina el 95% del ruido automatizado.

6. Secretos fuera del código y del historial de git

Audita tu repositorio ahora. Si hay claves API, tokens de base de datos o credenciales de Stripe en el código, tienes un problema. Y si alguna vez los tuviste y los "borraste" sin reescribir historial, siguen ahí.

# Detecta secretos en el historial completo
docker run --rm -v "$(pwd)":/repo trufflesecurity/trufflehog:latest git file:///repo --only-verified

# O con gitleaks
gitleaks detect --source . --verbose

Si encuentras alguno, rótalo inmediatamente (asume que está comprometido) y luego reescribe historial con git filter-repo o BFG Repo-Cleaner.

Fase 2 — Series A (3-6 backend devs, releases semanales, primeros clientes enterprise)

Aquí pasas de "no aparecer en titulares" a "poder responder un cuestionario de seguridad de un cliente sin sudar". El equipo crece, los endpoints se multiplican y la disciplina manual deja de escalar.

7. OpenAPI/Swagger actualizado como source of truth

A esta escala ya tienes 100+ endpoints. Si nadie sabe cuáles existen, nadie puede protegerlos — eso es API9 (Improper Inventory Management) en el OWASP API Top 10. La spec de OpenAPI deja de ser documentación para convertirse en infraestructura.

Dos reglas:

• Generación automática desde el código (decoradores en NestJS, FastAPI, drf-spectacular en Django). Una spec escrita a mano se desincroniza en una semana.
• CI rompe el build si un endpoint nuevo no está en la spec. Sin esto, vuelves al punto cero en un mes.

La spec actualizada es prerrequisito de los puntos 8 y 9.

8. Tests de autorización obligatorios en CI por cada endpoint

A 60 endpoints, la revisión manual de PR ya no atrapa todos los BOLA. La forma de no introducir regresiones es un test por endpoint que pruebe el caso "usuario A intenta acceder al recurso del usuario B".

test("member del workspace A no puede leer tareas del workspace B", async () => {
  const tokenA = await loginAs(memberOfWorkspaceA);
  const taskB = await createTaskInWorkspace(workspaceB);

  const res = await request(app)
    .get(`/api/tasks/${taskB.id}`)
    .set("Authorization", `Bearer ${tokenA}`);

  expect(res.status).toBe(404);
});

Marca este patrón como obligatorio en tu plantilla de PR. Cada endpoint nuevo que toca un recurso identificado tiene que traer su test de autorización cruzada.

9. DAST automatizado contra staging, semanal

El testing manual no escala a 100+ endpoints con releases semanales. Conecta una herramienta DAST que parsee tu OpenAPI y ejecute pruebas sistemáticas contra staging después de cada deploy nocturno.

Lo mínimo que tiene que hacer el escáner:

• Ejecutar cada endpoint con tokens de roles distintos (acceso cruzado para BOLA).
• Probar inyecciones básicas (SQLi, NoSQLi, XSS reflejado en JSON) en parámetros declarados.
• Detectar headers de seguridad ausentes y CORS permisivo.
• Reportar findings con la petición exacta y la respuesta vulnerable.

OWASP ZAP en modo API scan funciona si tienes tiempo de configurarlo y mantenerlo. La solución de seguridad de APIs de Vulnerabbit lo hace spec-aware sin que tengas que mantener scripts. La elección depende de cuánto tiempo de tu único backend dev quieres dedicar a operar el escáner vs. construir producto.

10. Logging con identidad de usuario y resultado

A esta escala ya tendrás incidentes (no graves, pero los tendrás). Y vas a necesitar reconstruir qué pasó. El logging mínimo por petición:

• user_id (o null si no autenticada).
• workspace_id (o tenant equivalente).
• Endpoint y método.
• Status code de respuesta.
• Latencia.
• IP de origen.

{
  "ts": "2026-05-05T09:14:22Z",
  "user_id": "usr_8h2k",
  "workspace_id": "ws_3xqp",
  "method": "DELETE",
  "path": "/api/tasks/tsk_9b1m",
  "status": 200,
  "latency_ms": 47,
  "ip": "203.0.113.42"
}

No necesitas un SIEM. Necesitas que estos logs estén en algún sitio queryable durante 90 días (CloudWatch Logs Insights, BigQuery, Loki, ELK gratuito).

11. Revisión trimestral de permisos y service accounts

Cada tres meses, una hora de tu calendario:

• Lista usuarios con rol owner en cada workspace interno. ¿Siguen necesitándolo?
• Lista service accounts y tokens de larga duración. ¿Quién los usa? ¿Hay alguno sin propietario claro?
• Lista integraciones de terceros con acceso a la API (Zapier, n8n, scripts internos). ¿Siguen activas?

Lo que no se revisa, se acumula. Lo que se acumula, se filtra.

Fase 3 — Series B+ (10+ backend devs, equipo de seguridad embrionario, clientes enterprise exigentes)

Ya no eres una startup pequeña. Tienes ingresos para invertir en seguridad como función, no como tarea de fin de sprint. El objetivo de la fase es la madurez programática.

12. Política formal de versionado y deprecación

A 10+ ingenieros tendrás múltiples versiones de tus endpoints conviviendo. Sin política, las versiones antiguas se acumulan indefinidamente y cada una es una superficie de ataque adicional.

La política mínima:

• Cada versión v(N) se anuncia como deprecated cuando sale v(N+1).
• Periodo de gracia documentado (típicamente 6-12 meses).
• Comunicación a clientes con calendario, no email genérico de última hora.
• Cuando se cumple el plazo, se apaga. Sin excepciones para "ese cliente que no migró".

13. Detección de Shadow APIs y endpoints olvidados

Con 10+ ingenieros tendrás endpoints de los que nadie se acuerda: el /api/internal/debug/dump de hace dos años, el /api/v0/legacy/sync que sigue activo "por si acaso", el /api/admin/migrate que solo se usó una vez.

Combina dos enfoques:

• Diff entre tu OpenAPI y los endpoints reales en producción (tráfico observado en logs/APM). Cualquier endpoint en producción que no esté en la spec es una shadow API.
• Escaneo activo desde fuera con herramientas EASM o discovery de tu plataforma DAST.

Cada shadow API que encuentres: o se documenta y se asegura, o se apaga. No hay tercera opción.

14. Programa de bug bounty privado o pentesting recurrente

A esta escala ya tienes el músculo interno para gestionar reports externos sin saturarte. Empieza con un programa privado en HackerOne o Intigriti (invitación a 20-50 investigadores), no público. Si no tienes ancho de banda para gestionar bug bounty, contrata pentesting externo trimestral con alcance específico (cada trimestre cubre un área distinta de la API).

Qué deliberadamente no está en este checklist

Estas son cosas que verás en otras guías y que no te recomiendo en startups pequeñas:

• WAF gestionado de pago antes de la Fase 3. Cloudflare gratis cubre el 90% de los casos. Pagar por WAF antes de tener los puntos 1-11 cubiertos es comprar una alarma para una casa con la puerta abierta.
• mTLS entre servicios internos antes de la Fase 3. Útil cuando tienes microservicios, contraproducente cuando tienes un monolito y dos servicios auxiliares.
• API gateway dedicado (Kong, Tyk, etc.) en Fase 1. Tu framework ya hace lo necesario. Añade complejidad operacional sin beneficio real hasta que tengas múltiples equipos publicando APIs.
• Certificación SOC 2 / ISO 27001 sin que un cliente te lo exija. Cuando lo pidan, cubrirlo será mucho más rápido si has seguido los puntos 1-11.
• Contratar un CISO antes de tener los puntos de Fase 1 y 2 cubiertos. Un advisor fraccional una tarde al mes es suficiente hasta los 50 empleados.

Cómo te ayuda Vulnerabbit a mantener este checklist

La parte difícil de un checklist no es escribirlo: es no dejar de aplicarlo cuando llega la presión del release. Los puntos 7, 8, 9, 10 y 13 — los que escalan con tu API y no con tu fuerza de voluntad — se pueden automatizar.

Vulnerabbit para SaaS parsea tu OpenAPI, ejecuta DAST spec-aware en cada deploy, prueba acceso cruzado entre roles para detectar BOLA y descubre shadow APIs comparando tráfico real con tu spec. Para equipos con 1-2 backend devs, la diferencia entre mantener el checklist y abandonarlo a los tres meses suele estar en si el escaneo se ejecuta solo o requiere que alguien se acuerde de lanzarlo.

¿Necesitas seguridad de APIs sin tener equipo de seguridad?

La plataforma de seguridad de APIs de Vulnerabbit automatiza los controles de Fase 2 y 3 — DAST spec-aware, detección de BOLA por acceso cruzado, descubrimiento de shadow APIs — para equipos que no tienen un dev de seguridad dedicado.

Lanzar escaneo gratuito → · Ver /solutions/api-security →