Escribiste una API, todo funciona, las pruebas pasan, el front-end sacude los puntos finales, todo perfecto. Y luego alguien vierte el token en un repositorio público, el bot comienza a golpear tu servidor con 10.000 solicitudes por segundo, y el aprendiz elimina accidentalmente la base de producción a través de la API.
Bienvenido al mundo de la seguridad de las API. Analicemos los tres pilares principales en los que se basa todo, y donde los desarrolladores tropiezan con más frecuencia.
🎫 1. Tokens: tu pase digital
¿Qué es y para qué sirve?
Un token es una cadena que le dice al servidor: "Soy quien digo ser". Sin un token, cualquier solicitud a una API segura recibirá un 401 Unauthorized frío como respuesta.
Los esquemas más populares:
API Key — una clave simple en el encabezado o parámetro de consulta. Cómodo, pero tosco.
JWT (JSON Web Token) — token autosuficiente con payload, firma y vida útil.
OAuth 2.0 Access Token — se emite a través del servidor de autorización, ideal para aplicaciones de terceros.
¿Dónde se equivocan?
❌ Almacenamiento de tokens en el código
Un clásico del género. El desarrollador escribe const API_KEY = "sk-live-abc123..." directamente en el código fuente. Lo sube a GitHub. El bot encuentra la clave en 30 segundos. Hola, fuga.
// ❌ Así lo hacen solo los enemigos de sí mismosconst API_KEY = "sk-live-abc123def456";
// ✅ Las variables de entorno lo son todo const API_KEY = process.env.API_KEY;❌ Tokens sin vida útil
Se emite un token y vive para siempre. Si lo roban, el atacante obtiene acceso ilimitado. JWT sin exp es como una llave de apartamento que no se puede volver a emitir.
❌ Transferencia de tokens a través de URL
Cuando el token se envía en el parámetro de consulta (?token=abc123), se instala en los registros del servidor, en el historial del navegador y en la analítica. Utiliza siempre el encabezado Authorization:
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
❌ Falta de rotación
La misma clave se utiliza durante años. La regla es simple: cambia las claves regularmente y usa un par de tokens de acceso/actualización.
🚦 2. Limitación de velocidad: frenos para la API
¿Qué es y para qué sirve?
El límite de velocidad es un límite en el número de solicitudes por unidad de tiempo. Sin él, un cliente agresivo (o bot) puede colapsar todo el servicio.
¿Dónde se equivocan?
❌ El límite de velocidad no está configurado en absoluto
Sorprendentemente, muchas API se lanzan al mercado sin ninguna restricción. Mientras el tráfico sea pequeño, no hay problema. Pero el primer ataque DDoS o un script descuidado con un ciclo infinito y el servidor se cae.
❌ Límite solo por IP
Parece lógico, pero una oficina completa o una VPN pueden esconderse detrás de una sola IP. Y un atacante puede distribuir solicitudes a miles de direcciones. Es mejor limitar por token/usuario:
# Ejemplo con Redis en Pythondef check_rate_limit(user_id):
key = f"rate:{user_id}"
current = redis.incr(key)
if current == 1:
redis.expire(key, 60) # ventana — 60 segundos
if current > 100:
raise RateLimitExceeded()❌ No hay respuestas informativas
Cuando un cliente alcanza el límite, debe entender lo que ha sucedido. Proporciona 429 Too Many Requests y títulos útiles:
HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1700000000
❌ Los mismos límites para todos los puntos finales
Las consultas GET /users y POST /payments son operaciones completamente diferentes en términos de carga y criticidad. Las operaciones pesadas y sensibles (pago, envío de cartas, generación de informes) deben tener límites más estrictos.
👑 3. Permisos: no todos son iguales
¿Qué es y para qué sirve?
Incluso si el usuario está autenticado (sabemos quién es), esto no significa que pueda hacer cualquier cosa. La autorización responde a la pregunta «¿qué se te permite exactamente?».
¿Dónde se equivocan?
❌ Verificación de derechos solo en el frontend
¿El botón «Eliminar» está oculto en la interfaz de usuario para un usuario normal? Perfecto. Pero si envía DELETE /api/users/42 directamente a través de curl, el servidor ejecutará la solicitud. La verificación de derechos debe estar en el backend. Siempre.
// ❌ Frontend «protección»
{role === 'admin' && <button onClick={deleteUser}>Удалить</button>}
// ✅ Verificación de backend: obligatoria
app.delete('/api/users/:id', (req, res) => {
if (req.user.role !== 'admin') {
return res.status(403).json({ error: 'Forbidden' });
}
// ... eliminación
});❌ IDOR — Insecure Direct Object Reference
Una de las vulnerabilidades más comunes. El usuario solicita GET /api/orders/123 y ve su pedido. Cambia 123 a 124 y ve el de otra persona. El servidor no comprueba si el recurso pertenece al usuario actual:
// ❌ Confiamos en el ID de la URL sin verificar el propietario
app.get('/api/orders/:id', async (req, res) => {
const order = await Order.findById(req.params.id);
res.json(order); // cualquier pedido
});
// ✅ Filtrar por propietario
app.get('/api/orders/:id', async (req, res) => {
const order = await Order.findOne({
_id: req.params.id,
userId: req.user.id // solo sus pedidos
});
if (!order) return res.status(404).json({ error: 'Not found' });
res.json(order);
});❌ Alcance demasiado amplio de los tokens
OAuth permite emitir tokens con derechos limitados (scopes). Pero los desarrolladores a menudo solicitan scope: *, es decir, acceso completo a todo. Si se filtra un token de este tipo, las consecuencias serán máximas. Principio de privilegio mínimo: otorga exactamente tantos derechos como sean necesarios para una tarea específica.
❌ No hay separación de roles
Dos tipos de usuarios: «autorizado» y «no autorizado». Y se necesita: admin, manager, user, readonly, service. Un modelo de roles competente no es una sobreingeniería, sino una necesidad.
🚀 ¿Quieres profundizar?
Si acabas de empezar tu viaje en la programación o quieres mejorar tus habilidades prácticas, pruébalo Kodik. Esta es una aplicación en la que aprendes programación a través de la práctica: no solo lees la teoría, sino que escribes código y resuelves problemas.
Y también entra en nuestro comunidad en Telegram — allí se publican regularmente publicaciones útiles sobre desarrollo, análisis de tareas y materiales nuevos. ¡Ya somos más de 2000 desarrolladores!
No seas el desarrollador cuya API sale en las noticias. Comprueba tu lista de verificación hoy. 🔒