Tema 14
Las aplicaciones modernas ya no entregan toda la logica desde paginas HTML tradicionales. Gran parte del negocio viaja por APIs consumidas por navegadores, aplicaciones moviles, sistemas internos y servicios de terceros. Eso amplifica la superficie de ataque y obliga a proteger datos, endpoints, tokens y flujos automatizados con criterios distintos a los de una interfaz visual clasica.
Una API web es una interfaz programatica accesible mediante HTTP que permite consultar, crear, modificar o eliminar informacion. A diferencia de una pagina HTML pensada para seres humanos, una API esta diseñada para que otros programas interactuen con ella de forma automatizada.
Eso cambia bastante el problema de seguridad. En una API no importa solo lo que ve el usuario en pantalla, sino tambien lo que cualquier cliente puede invocar directamente si conoce la ruta, el metodo y el formato esperado. Un atacante no necesita usar la interfaz oficial; puede construir peticiones manuales, automatizarlas y probar miles de variantes en poco tiempo.
Por eso, proteger APIs requiere pensar en autenticacion, autorizacion, validacion de datos, exposicion minima, control de volumen, trazabilidad y configuracion segura del intercambio entre origenes.
En una aplicacion clasica renderizada en servidor, muchas reglas parecen asociadas a formularios, botones y pantallas. En una arquitectura basada en APIs, el frontend suele ser un consumidor mas de endpoints que exponen operaciones de negocio.
Eso implica una regla fundamental: nada importante debe confiar en la interfaz. Si una accion depende de permisos, estado del recurso, identidad o validaciones de negocio, todo debe comprobarse del lado servidor, incluso si el frontend ya oculta botones o restringe opciones.
Muchas APIs siguen principios REST. Exponen recursos por rutas como /usuarios, /pedidos o /facturas y operan sobre ellos con metodos HTTP como GET, POST, PUT, PATCH y DELETE. Esta organizacion es util, pero no garantiza seguridad.
Los problemas aparecen cuando una API publica endpoints innecesarios, permite operaciones mas amplias de lo debido o asume que un identificador recibido por URL corresponde automaticamente al recurso que el cliente puede tocar.
En APIs, los errores de control de acceso son especialmente frecuentes porque el atacante puede iterar rutas, cambiar identificadores y automatizar pruebas con muy poco esfuerzo.
El formato mas usado en APIs web es JSON. Su simplicidad favorece integracion y legibilidad, pero tambien puede generar exceso de confianza. Que un payload sea legible no significa que sea seguro.
Un cuerpo JSON puede incluir campos inesperados, tipos incorrectos, estructuras anidadas enormes, listas fuera de rango o atributos que el cliente nunca deberia enviar. Si el backend mapea automaticamente ese objeto a entidades internas sin control estricto, aparecen fallas de validacion, mass assignment o estados inconsistentes.
Una API madura define con precision que campos acepta, cuales ignora, cuales rechaza y cuales recalcula del lado servidor.
Gran parte de estos problemas no se ve desde la interfaz grafica. Se descubren observando el contrato real de la API y probando que hace el backend ante consumidores no previstos.
Una API debe saber quien hace la peticion antes de permitir operaciones sensibles. La autenticacion puede basarse en sesiones, tokens, claves de API, OAuth u otros mecanismos, segun el contexto. Lo importante es que la identidad del cliente quede representada de forma verificable y resistente a manipulacion.
Un error comun es mezclar autenticacion con simple identificacion. Que el cliente envie un userId, un correo o un nombre de cuenta no significa que esa identidad haya sido probada. La API debe derivar la identidad desde un mecanismo confiable y no desde parametros controlados por el cliente.
Autenticar significa saber quien es el cliente. Autorizar significa decidir que puede hacer. En APIs, la autorizacion debe comprobarse por cada solicitud sensible y, muchas veces, por cada objeto accedido.
Si un usuario autenticado consulta /api/pedidos/1001, la API no debe asumir que puede verlo solo porque la peticion incluye un token valido. Debe verificar si ese pedido pertenece a ese usuario o si ese rol tiene permiso para acceder.
Esta es la raiz de muchas fallas tipo IDOR y de gran parte de las exposiciones de datos entre usuarios autenticados.
JWT significa JSON Web Token. Es un formato de token firmado que puede transportar claims, es decir, datos sobre la identidad o el contexto de la sesion. Se usa con frecuencia en APIs porque permite representar autenticacion sin almacenar necesariamente estado de sesion tradicional en el servidor.
Un JWT suele incluir informacion como sujeto, emisor, fecha de expiracion y permisos o alcances. Si esta bien implementado, el servidor puede validar la firma y confiar en que el contenido no fue alterado.
El problema es que muchas implementaciones tratan al JWT como si fuera seguro por definicion. En realidad, su seguridad depende de como se genere, firme, transporte, valide y revoque.
JWT puede ser util para desacoplar servicios, reducir dependencia de una sesion central o integrar clientes heterogeneos. Sin embargo, tambien complica revocacion inmediata, cierre de sesion global y cambios dinamicos de permisos si no existe una estrategia complementaria.
Por eso conviene evitar convertir al JWT en un contenedor ilimitado de estado. Cuanto mas tiempo vive el token y mas decisiones de seguridad delega, mayor es el riesgo cuando se filtra o cuando cambian las condiciones del usuario.
CORS es un mecanismo del navegador que regula si una pagina de un origen puede leer respuestas de otro origen. Sirve para permitir o restringir interacciones entre frontend y API cuando estan en dominios, subdominios o puertos distintos.
Es importante entender que CORS no es un sistema de autenticacion ni un reemplazo de autorizacion. Solo controla que navegadores obedientes pueden leer ciertas respuestas cross-origin. No protege una API frente a clientes directos, scripts propios, herramientas de prueba ni llamadas hechas fuera del navegador.
* sin necesidad real.La configuracion correcta de CORS debe ser explicita, minima y coherente con los frontends reales que consumen la API.
Una API publica facilita automatizacion. Eso es una ventaja funcional, pero tambien una puerta para fuerza bruta, scraping, enumeracion masiva, denegacion parcial de servicio o abuso de costos en recursos intensivos.
El rate limiting impone limites de cantidad o velocidad por cliente, token, usuario, IP, clave o combinacion de factores. Su objetivo no es solo disponibilidad. Tambien ayuda a frenar ataques de autenticacion, prueba de identificadores, extraccion de datos y abuso repetitivo de endpoints costosos.
No siempre alcanza con un unico limite global. Segun el negocio, puede ser necesario combinar:
Una API segura diferencia trafico normal de patrones de abuso y responde con degradacion controlada, no con colapso.
Uno de los problemas mas frecuentes en APIs es devolver mas informacion de la necesaria. A veces ocurre porque el backend serializa entidades completas y el frontend solo usa una parte. Otras veces se incluyen campos internos, tecnicos o sensibles por comodidad de desarrollo.
Esto puede exponer correos, identificadores internos, estados administrativos, historiales, banderas de seguridad o relaciones que luego facilitan otros ataques. La respuesta de una API debe estar pensada como contrato minimo, no como volcado completo del objeto interno.
Cuando un cliente envia JSON, la API debe validar estructura, tipo, obligatoriedad, rango y coherencia del contenido. Si el backend acepta automaticamente cualquier campo que coincida con propiedades del modelo interno, aparece el riesgo de mass assignment.
Eso significa que el atacante puede intentar enviar atributos que no deberia controlar, como role, isAdmin, status, price o marcas de aprobacion. Aunque la interfaz nunca exponga esos campos, la API podria procesarlos si no existe una allowlist estricta.
El crecimiento de una API suele dejar endpoints viejos, rutas experimentales, parametros heredados y contratos ambiguos. Todo eso aumenta superficie de ataque. Versionar ayuda a evolucionar sin romper clientes, pero tambien exige retirar lo obsoleto y documentar claramente que sigue activo.
Una API segura expone solo lo necesario. Endpoints no usados, metodos sin finalidad actual, respuestas excesivas o parametros heredados representan complejidad innecesaria y oportunidades de error.
Las APIs necesitan errores utiles para integradores, pero no deben filtrar implementacion interna, consultas, stacks ni secretos. Una respuesta demasiado detallada facilita reconocimiento del sistema y afinado de ataques.
Al mismo tiempo, el servidor si debe registrar contexto suficiente para investigar: endpoint, identidad, origen, tipo de error, correlacion, volumen y patron. La clave es separar la informacion operativa que ve el cliente de la telemetria que conserva el sistema.
| Area | Buena practica | Riesgo que reduce |
|---|---|---|
| Identidad | Autenticacion fuerte y validacion estricta de tokens | Suplantacion y acceso no autorizado |
| Acceso | Autorizacion por recurso y por accion | IDOR y escaladas horizontales o verticales |
| Datos | Respuestas minimas y schemas definidos | Exposicion excesiva y estados inconsistentes |
| Abuso | Rate limiting, cuotas y deteccion de patrones | Fuerza bruta, scraping y saturacion |
| Origen | CORS explicito y acotado | Integraciones inseguras desde navegador |
| Operacion | Logs utiles sin filtrar detalles internos al cliente | Dificultad de respuesta o exceso de informacion expuesta |
Imaginemos una aplicacion movil que consume una API de pedidos. El usuario inicia sesion y recibe un JWT. Luego consulta /api/pedidos/123. Si la API valida la firma del token pero no comprueba que ese pedido pertenece al usuario autenticado, aparece una falla de autorizacion. Si ademas la respuesta incluye direccion completa, datos de facturacion y notas internas, existe exposicion excesiva. Si no hay rate limiting, un atacante puede automatizar miles de consultas cambiando el identificador.
Y si la API tiene CORS abierto para cualquier origen con credenciales, un frontend mal configurado puede ampliar aun mas el problema en navegadores. Este ejemplo muestra que la seguridad de APIs no depende de un unico control, sino de varias capas coherentes entre si.
Las APIs se han convertido en el corazon operativo de muchas aplicaciones web. Eso las vuelve extremadamente utiles, pero tambien extremadamente atractivas para atacantes. Protegerlas exige pensar mas alla de la interfaz: identidad confiable, permisos bien aplicados, contratos estrictos, volumen controlado y datos minimos.
En el proximo tema veremos registro, monitoreo, deteccion y respuesta ante incidentes web, porque una aplicacion segura no solo previene: tambien necesita ver, entender y responder cuando algo anomalo ocurre.