Pruebas de Seguridad de API: Una Guía Completa

Tus comprobaciones existentes probablemente demuestran bien una sola cosa: que el servicio se comporta correctamente para quien sigue las reglas. Si también rechaza a quienes no lo hacen es una pregunta distinta, y una a la que la mayoría de los ciclos de lanzamiento nunca llega. Las pruebas de seguridad de API observan si alguien que ya sabe cómo comunicarse con tus endpoints puede hacer que se comporten mal.

Examina cómo manejas los inicios de sesión y los tokens, si cada solicitud tiene permitido hacer lo que pide, cuánto tráfico permites, y qué revelan tus respuestas. Este trabajo tiene su propia lista de riesgos, el OWASP API Security Top 10. No es lo mismo que la versión general de aplicaciones web que sigue la mayoría de las listas de verificación.

Tres de los diez riesgos de API son fallos de autorización, donde el servicio sabe exactamente quién pregunta y aun así entrega registros que pertenecen a otra persona. Una lista de verificación de aplicaciones web mete todo eso en una categoría amplia. Buscamos esos fallos durante la QA cotidiana, y ejecutamos servicios de pruebas de penetración cuando un lanzamiento requiere una revisión más profunda y acotada.

El resto de esta guía trata sobre cómo comprobar cada uno de ellos.

En Qué se Diferencian las Pruebas de Seguridad de API de las de Aplicaciones Web

Las pruebas de seguridad de aplicaciones web asumen a una persona en un navegador. Alguien rellena un formulario, lo envía, y la pantalla decide qué mostrarle. Por eso, gran parte de la protección vive en esa página: campos que no puedes editar, botones que nunca ves, menús que ocultan cualquier cosa que no debas alcanzar.

Una API no tiene nada de eso. Responde a quien envíe una solicitud correctamente formada, y quien llama suele ser un script en lugar de una persona. Entonces, ¿qué es la prueba de seguridad de API en la práctica? Es el trabajo de demostrar que tu API rechaza las solicitudes que debería rechazar, incluso cuando provienen de una cuenta que inició sesión correctamente.

Este es el cambio que sorprende a los equipos. Las pruebas web clásicas dedican la mayor parte de su esfuerzo a mantener fuera a los desconocidos. En cambio, en una API partes de la premisa opuesta: quien llama ya tiene un token válido. La pregunta interesante ya no es cómo llegó ahí, sino hasta dónde puede llegar ahora que lo tiene.

Eso tiene dos consecuencias prácticas:

• Tu lógica de negocio queda expuesta en lugar de envuelta en una interfaz, así que una comprobación en el frontend no protege nada.
• Un script puede repetir una sola solicitud miles de veces por minuto, lo que convierte un pequeño descuido en uno grande.

Las dos listas de OWASP reflejan esta división. En el lado de aplicaciones web, el control de acceso defectuoso es una sola entrada que cubre desde una página de administración oculta hasta un ID de registro manipulado. La versión de API divide el mismo terreno en tres riesgos separados, porque esos fallos se ven y se comportan de forma distinta aquí. Para el equivalente web, nuestra lista de verificación de pruebas de penetración de aplicaciones web lo repasa, mientras que nuestra práctica de pruebas de seguridad cubre ambas superficies.

¿Qué Es el OWASP API Security Top 10?

El OWASP API Security Top 10 es la referencia para este trabajo, actualmente en su edición de 2023. Las pruebas de seguridad de endpoints de API suelen seguirla de cerca, porque cada elemento nombra un fallo que puedes ir a comprobar en lugar de un principio a tener en cuenta.

Vale la pena aclarar un punto de nomenclatura primero. Si has leído sobre “exposición excesiva de datos” como riesgo de API, ese era el tercer elemento de la edición de 2019. Se fusionó en API3 durante la revisión de 2023, así que el término antiguo sigue apareciendo en artículos y herramientas mientras la lista actual lo llama de otra forma.

Las Tres Formas en que Falla la Autorización de API

Estas entradas describen el mismo error subyacente a distintas escalas. Juntas son donde comienzan la mayoría de los incidentes reales de API, y explican por qué este perfil de riesgo no puede simplemente heredar una lista de verificación de aplicaciones web.

• API1, a nivel de objeto. Tu API identifica al llamante, luego falla al preguntar si es dueño del registro concreto que solicitó. Por ejemplo, una búsqueda de la factura 1041 tiene éxito, así que alguien prueba 1042 y recibe la factura de un desconocido. Encontrarlo es poco glamuroso y efectivo: inicia sesión como un cliente, recopila los identificadores que legítimamente posees, luego solicita los que no tienes y observa qué devuelve. Una API correcta responde con un rechazo. La vulnerable entrega los datos.
• API3, a nivel de propiedad. Aquí el registro sí te pertenece, pero el intercambio lleva más de lo que debería en una dirección u otra. Un perfil de cliente podría devolver una puntuación de riesgo interna o un token de restablecimiento junto al nombre y la dirección, porque el endpoint envía el objeto completo y confía en que la app muestre solo una parte. Lo contrario también ocurre, donde una actualización acepta un campo como role o account_balance que ningún cliente debería poder establecer. Ambas direcciones necesitan pruebas, porque una respuesta que la app nunca muestra igualmente ha salido de tu servidor.
• API5, a nivel de función. Esta vez la operación está fuera de límites en lugar del registro. Una cuenta estándar llama a la ruta de un administrador y funciona, porque nada detrás vuelve a comprobar quién pregunta. En un sitio web, una pantalla de administración permanece oculta de la navegación y en su mayoría olvidada. Una API no tiene menú, así que cada acción privilegiada necesita su propia protección, y cada una debe probarse desde una cuenta ordinaria.

Fíjate en lo que las tres tienen en común: nada se rompió por la fuerza. Cada solicitud estaba correctamente formada, correctamente autenticada, y respondida exactamente como el código pretendía. Por eso sobreviven tan cómodamente a las pruebas funcionales, y por eso detectarlas requiere un caso que deliberadamente pida algo que no debería recibir.

Qué Comprobar para los Siete Riesgos Restantes

Estas siguen importando, aunque cada una necesita menos desarrollo.

• API2, autenticación. Observa cómo se emiten los tokens, cuánto tiempo permanecen válidos, si uno sigue funcionando después de cerrar sesión, y si un flujo de restablecimiento de contraseña puede recorrerse hacia atrás.
• API4, consumo de recursos. Envía más tráfico del que cualquier cliente real generaría, payloads sobredimensionados, y consultas que sabes que son costosas. Quieres un rechazo claro en lugar de un colapso lento.
• API6, flujos de negocio. Pregúntate qué podría hacer un competidor o un revendedor con acceso automatizado ilimitado a una función que funciona correctamente. La compra de entradas y el canje de vales son los ejemplos habituales.
• API7, falsificación de solicitud. En cualquier lugar donde tu API acepte una dirección web, apúntala a infraestructura interna y observa si obedece.
• API8, configuración. Errores habladores, encabezados ausentes, y reglas que dejan que cualquier sitio web llame a tu API viven todos aquí. Nuestro explicador sobre configuración de seguridad incorrecta cubre el patrón con más profundidad.
• API9, inventario. Averigua qué sigue siendo alcanzable. Versiones antiguas, rutas de staging, y endpoints ausentes de la documentación son comunes, y lo que nadie mantiene tampoco se parchea.
• API10, consumo inseguro. Trata los datos que llegan de servicios externos con la misma sospecha que aplicas a la entrada del usuario, porque una integración de confianza igualmente puede enviarte algo malformado.

Cómo REST, GraphQL, gRPC, y SOAP Cambian lo que Pruebas

La lista OWASP es deliberadamente neutral respecto al protocolo, lo cual ayuda en la planificación y se queda corta en la ejecución. Las pruebas de seguridad de API tienen que tener en cuenta cómo se comunica realmente tu servicio, porque el mismo riesgo aparece en un lugar distinto según la tecnología subyacente.

REST y GraphQL

REST es donde la autorización a nivel de objeto falla más a menudo, por razones estructurales más que culturales. Una dirección REST nombra la cosa que estás pidiendo, así que el identificador está justo ahí para editarse. Nada en el estilo lo hace menos seguro, pero sí hace que un error concreto sea inusualmente fácil de cometer y sencillo de encontrar. La versión detallada de esa comprobación pertenece a una lista de verificación de seguridad específica de REST.

GraphQL traslada la exposición a otro lugar. Como el cliente compone su propia consulta, una sola solicitud puede pedir datos profundamente anidados y costosos que ninguna ruta REST permitiría. Eso convierte API4 en una decisión de diseño en lugar de un ajuste de límite de tasa. El otro descuido frecuente es la introspección: la función que permite a cualquier cliente pedir a la API que describa su propia estructura. Dejada habilitada públicamente, entrega a un visitante un mapa completo de tu modelo de datos.

gRPC y SOAP

gRPC parece más seguro por defecto, en gran parte porque no hay herramientas de navegador convenientes y los mensajes son ilegibles para una persona. Eso juega en tu contra durante las pruebas más de lo que ayuda en producción. La reflexión de servicio, que permite a un llamante listar cada método disponible, entrega a un extraño un mapa completo de tu servicio si la dejas activada. Los permisos entonces deben comprobarse en cada uno en lugar de asumirse desde el transporte.

SOAP llega con una especificación de seguridad incorporada, llamada WS-Security, y eso crea una trampa propia. Configurarla no es lo mismo que aplicarla a cada operación. Los analizadores XML también traen una familia de problemas que los servicios construidos sobre JSON nunca encuentran.

¿Por Qué las Pruebas de Seguridad de API Pertenecen a QA?

El error más común que vemos es tratar las pruebas de seguridad de API como un proyecto puntual en lugar de trabajo rutinario. Se programa una vez al año, lo manejan especialistas externos, y se redacta semanas después del lanzamiento que describe.

Ese arreglo pasa por alto casi por completo los fallos de autorización, por una razón directa. Encontrarlos depende de entender qué se supone que hace el producto. Sin embargo, un revisor que llega para dos semanas no tiene forma de saber qué campos debería ver un cliente, qué rutas son solo de administrador, o quién es dueño de qué registro. Tus ingenieros de QA lo saben todo, porque escribieron las pruebas funcionales que codifican esas reglas.

La solución es un pequeño hábito en cada lanzamiento. Quien comprueba un endpoint también pide un registro que no posee, y confirma el rechazo. Nuestro trabajo de pruebas de API está construido así, con los casos de seguridad ejecutándose junto a los cotidianos en lugar de detrás de ellos.

Vimos eso en Union54, una API de emisión de tarjetas para fintechs africanas, probada sin interfaz alguna. Algunos de los defectos que reportamos eran fallos de autorización entre distintos tipos de usuarios. Nada de eso salió de una revisión de seguridad dedicada. En cambio, esos hallazgos pertenecían a ingenieros de QA que conocían el producto lo bastante bien como para notar cuándo la persona equivocada recibía la respuesta correcta.

Eso no vuelve redundante el trabajo especializado. Una prueba de penetración acotada sigue ganándose su lugar antes de un lanzamiento importante, o cuando un regulador o un cliente grande pide una. Sin embargo, rinde más una vez que se cierran las brechas obvias. Los especialistas entonces dedican su tiempo a problemas que solo ellos pueden encontrar.

Cómo Crear una Lista de Verificación de Pruebas de Seguridad de API

Saber cómo probar la seguridad de API resulta ser menos sobre lo que contiene la lista y más sobre quién es su dueño. Muchos equipos tienen un documento, pero casi nadie lo abre durante un lanzamiento.

Organiza la tuya en torno a las categorías de OWASP en lugar de tus endpoints. Un inventario ruta por ruta se queda obsoleto la semana después de escribirlo, mientras que esas agrupaciones de riesgo se mantienen estables a través de lanzamientos y tecnologías. Bajo cada una, registra qué se comprueba, a qué rutas se aplica, y quién lo aprueba.

Cuatro decisiones hacen más por una lista de verificación que su contenido:

• Dale un único dueño con la autoridad para bloquear un lanzamiento, nunca una bandeja de entrada compartida.
• Vincúlala al proceso de lanzamiento que tu equipo ya sigue en lugar de un calendario de seguridad separado.
• Escribe cada entrada como una solicitud más un rechazo esperado, para que cualquiera pueda ejecutarla y leer el resultado.
• Revísala cada vez que añadas una ruta, cambies un modelo de permisos, o incorpores una nueva integración de terceros.

Dos piezas adyacentes vale la pena mantener abiertas junto a ella:

• Nuestra lista de verificación de pruebas de API REST cubre la mitad de fiabilidad, y la superposición es útil, ya que un caso de seguridad a menudo es uno funcional con el resultado esperado invertido.
• Nuestro trabajo sobre pruebas de rendimiento de API también pertenece aquí, porque lo que sea que limite el abuso también te lleva a través de un pico de tráfico.

Una advertencia sobre las herramientas. Los escáneres funcionan bien en configuración incorrecta y manejo de tokens, donde los errores siguen patrones reconocibles. Son casi inútiles en los tres riesgos de autorización, porque ninguna herramienta puede saber quién debería poseer una factura determinada. Solo tu equipo tiene ese conocimiento, así que el trabajo pertenece dentro del aseguramiento de calidad en lugar de fuera de él.

Auditamos las API contra la lista OWASP en cualquier etapa en que se encuentre tu producto, ya sea que la construcción esté terminada o los endpoints todavía se estén escribiendo. Para descubrir qué le entrega tu API a un llamante que pide más de lo que debería, habla con nuestro equipo de QA.

¿Qué es la prueba de seguridad de API?

La prueba de seguridad de API comprueba si una API puede ser mal utilizada por alguien que ya tiene credenciales válidas. Cubre la autenticación, la autorización en cada solicitud, los límites de tasa y payload, y lo que revelan las respuestas. El marco de referencia es el OWASP API Security Top 10, que difiere de la lista general de aplicaciones web porque el riesgo de API se concentra en la autorización en lugar de la inyección.

¿Necesita GraphQL pruebas de seguridad distintas a REST?

Sí, aunque la lista OWASP se aplica a ambas. REST expone los identificadores de registro en la dirección, así que la primera comprobación es si cambiar uno devuelve los datos de otro cliente. GraphQL permite al cliente componer su propia solicitud, lo que traslada los riesgos a la profundidad de la consulta, los límites de costo, y si la introspección es pública.

¿En qué se diferencia la lista OWASP de API de la de aplicaciones web?

La lista de aplicaciones web trata el control de acceso como una categoría amplia. La lista de API la divide en tres: a nivel de objeto, a nivel de propiedad del objeto, y a nivel de función. Eso refleja cómo ocurren realmente los fallos de API, donde un llamante correctamente autenticado recibe registros que pertenecen a otra persona. Los riesgos de inyección y scripting, que dominan las pruebas web, importan menos en la mayoría de las API.

¿Puede la QA funcional encontrar problemas de seguridad de API?

Sí, y para los fallos de autorización suele ser el lugar más efectivo donde buscar. Encontrarlos significa saber quién debería ver cada registro, y tus ingenieros de QA ya codifican esas reglas en pruebas funcionales. Escribir el caso negativo junto al positivo detecta la mayoría de esos fallos de autorización mucho antes de que llegue una revisión especializada.

¿Con qué frecuencia debe ejecutarse la prueba de seguridad de API?

Ejecuta las comprobaciones de autorización y entrada en cada lanzamiento, dentro de tu ciclo de pruebas normal, porque un solo cambio de permiso puede abrir una brecha. Reserva las pruebas de penetración con alcance definido para lanzamientos importantes, cambios de arquitectura, o un requisito de cumplimiento. Las pruebas anuales por sí solas te dejan expuesto durante los once meses en que el producto sigue cambiando.