Las pruebas negativas de APIs no consisten en enviar valores aleatorios hasta provocar un error. Su objetivo es demostrar que el sistema rechaza de forma segura las solicitudes inválidas, protege los recursos y conserva un estado consistente cuando algo sale mal. Una buena respuesta negativa también forma parte del producto: debe ser predecible, útil para el consumidor y no exponer información interna.
En producción, las APIs reciben tokens vencidos, mensajes incompletos, reintentos simultáneos y solicitudes que llegan en un orden inesperado. Algunas situaciones son errores del consumidor; otras aparecen por latencia, fallos de red o dependencias degradadas. Diseñar la cobertura desde esos riesgos permite encontrar defectos que el camino feliz nunca mostrará.
Qué debe demostrar una prueba negativa de API
Una prueba negativa útil comprueba cuatro resultados:
- la API rechaza la condición inválida con la semántica adecuada;
- la respuesta permite al consumidor entender el problema sin revelar secretos;
- no se produce un cambio parcial, duplicado o no autorizado;
- el sistema conserva capacidad de recuperación y diagnóstico.
Esto significa que comprobar un 400 es apenas el comienzo. También hay que revisar el cuerpo del error, los campos afectados, el identificador de correlación, los efectos persistidos y el comportamiento de servicios dependientes. La RFC 9110 diferencia errores del cliente 4xx de fallos del servidor 5xx; usar la clase incorrecta puede provocar reintentos innecesarios o esconder un defecto interno.
Pruebas negativas de APIs basadas en riesgo
1. Campos ausentes, nulos y vacíos
Prueba cada campo obligatorio ausente, pero evita crear combinaciones sin propósito. Distingue entre una propiedad omitida, un valor null, una cadena vacía y una cadena con espacios. El contrato puede tratar esas condiciones de manera diferente. Verifica que el error identifique el campo correcto y que la operación no guarde un registro incompleto.
2. Tipos, formatos y límites
Envía tipos incompatibles, fechas imposibles, monedas no soportadas, identificadores mal formados y valores justo fuera de los límites permitidos. Incluye extremos como cero, negativos, máximos y tamaños superiores al contrato. La meta no es “romper” el parser, sino confirmar una validación consistente antes de que los datos lleguen a capas más costosas.
3. Autenticación y expiración
Cubre ausencia de credenciales, token vencido, firma inválida y credenciales válidas para otro ambiente. Distingue autenticación de autorización: una persona puede estar correctamente identificada y aun así no tener permiso. Los errores no deberían confirmar si una cuenta específica existe ni devolver detalles del mecanismo interno.
4. Acceso a objetos y funciones no autorizadas
Cambia el identificador de un recurso perteneciente a otro usuario y ejecuta la misma operación con distintos roles. Revisa lectura, modificación y eliminación. El OWASP API Security Top 10 2023 ubica los fallos de autorización a nivel de objeto y de función entre los riesgos principales de las APIs.
No limites la comprobación al estado HTTP. Confirma que no cambió el recurso, que no se emitió un evento y que los mensajes de error no contienen propiedades sensibles. La exposición excesiva puede ocurrir incluso cuando la solicitud es rechazada.
5. Estados y secuencias inválidas
Intenta aprobar una orden cancelada, capturar un pago no autorizado o cerrar un proceso que aún tiene tareas pendientes. Estas pruebas requieren entender la máquina de estados del negocio. Una API madura rechaza transiciones imposibles y conserva el estado anterior sin efectos parciales.
6. Duplicados, reintentos y concurrencia
Repite la misma solicitud, reutiliza una clave de idempotencia con parámetros diferentes y envía dos operaciones concurrentes contra el mismo recurso. Valida si una queda en progreso, es rechazada o devuelve el resultado original según el contrato. Después confirma que existe un único efecto de negocio.
7. Paginación, filtros y consumo de recursos
Prueba tamaños de página negativos, excesivos o ausentes; filtros incompatibles; rangos invertidos y consultas que podrían generar cargas desproporcionadas. OWASP incluye el consumo no restringido de recursos porque una solicitud válida en estructura puede agotar CPU, memoria, almacenamiento o servicios facturados por operación.
8. Dependencias lentas o no disponibles
Simula timeouts, respuestas inválidas y errores de servicios externos mediante dobles controlados o ambientes preparados. Comprueba el timeout del sistema, la cantidad de reintentos, el backoff y la respuesta final. Una API no debería confiar ciegamente en datos provenientes de terceros; OWASP denomina este riesgo consumo inseguro de APIs.
Matriz práctica de escenarios negativos
| Condición | Respuesta esperada | Validación adicional |
|---|---|---|
| Campo obligatorio ausente | 400 o 422 según contrato | No persiste información parcial |
| Token ausente o inválido | 401 | No revela datos del recurso |
| Rol sin permiso | 403 o respuesta definida | No ejecuta efectos secundarios |
| Recurso inexistente | 404 | Error estable y sin detalles internos |
| Conflicto de estado | 409 | Estado anterior intacto |
| Exceso de solicitudes | 429 | Header de reintento y límite efectivo |
| Dependencia no disponible | 502, 503 o respuesta definida | Timeout, reintentos y trazabilidad controlados |
Los códigos exactos dependen del contrato. Lo importante es que cada condición tenga una respuesta documentada y que los consumidores puedan distinguir un error corregible, un conflicto de negocio y un fallo transitorio.
Cómo diseñar datos negativos sin generar ruido
- Parte de reglas, límites, estados y permisos conocidos.
- Cambia una condición relevante por escenario para facilitar el diagnóstico.
- Genera identificadores y datos únicos cuando la prueba pueda ejecutarse en paralelo.
- Comprueba respuesta y ausencia de efectos no permitidos.
- Limpia únicamente los datos creados por la prueba.
Para entender todas las capas que acompañan estas comprobaciones, consulta qué validar en pruebas API REST además del código 200 y la estrategia general de pruebas de APIs para producción.
Qué automatizar y qué mantener exploratorio
Automatiza reglas estables, permisos críticos, límites conocidos, contratos de error y regresiones que deban ejecutarse en cada entrega. Mantén exploratorias las combinaciones nuevas, comportamientos poco comprendidos y escenarios cuya observación requiera criterio humano. Cuando un hallazgo se vuelve repetible y relevante, conviértelo en regresión.
En CI/CD, separa un conjunto rápido que bloquee cambios de una suite más amplia programada. Los escenarios que dependen de degradar servicios o generar carga necesitan ambientes controlados; no deberían ejecutarse indiscriminadamente contra sistemas compartidos.
Errores frecuentes en las pruebas negativas
- Generar cientos de combinaciones sin asociarlas a un riesgo.
- Comprobar solo que la API “no devolvió 200”.
- Aceptar cualquier
4xxcomo resultado válido. - No confirmar que la base de datos y los eventos quedaron intactos.
- Usar pruebas destructivas en un ambiente compartido sin aislamiento.
- Registrar credenciales o información personal en los reportes.
Preguntas frecuentes
¿Un error 500 es un resultado esperado en una prueba negativa?
Normalmente no cuando la solicitud contiene un error conocido del cliente. Un 500 indica que el servidor no manejó correctamente la condición. Debe registrarse como defecto salvo que el contrato documente otra razón específica.
¿Las pruebas negativas son pruebas de seguridad?
Algunas cubren riesgos de seguridad, especialmente permisos, exposición y consumo de recursos, pero no reemplazan una evaluación especializada. También validan negocio, resiliencia y calidad del contrato.
Conclusión
Las pruebas negativas de APIs son valiosas cuando demuestran control: la solicitud incorrecta se rechaza, el consumidor recibe una respuesta útil, el sistema no deja efectos parciales y el equipo puede diagnosticar lo ocurrido. Diseñarlas desde riesgos reales produce menos casos, mejor señal y una protección más cercana a lo que sucede en producción.