💡 Key Takeaways
- Authentication and Authorization: The Foundation That Everyone Rushes Past
- Request Validation: Where Most Bugs Actually Live
- Response Validation: Trust, But Verify
- State Management and Idempotency: The Subtle Art of Consistency
Hace tres años, vi cómo una API de producción fallaba espectacularmente a las 2 AM porque nadie probó qué sucede cuando envías un campo de fecha formateado como "32/13/2021". La cascada fue hermosa de la peor manera posible: 47,000 transacciones fallidas, clientes enojados inundando los canales de soporte, y un CEO que quería respuestas que no tenía. Esa noche cambió para siempre mi enfoque hacia las pruebas de API.
💡 Puntos Clave
- Autenticación y Autorización: La Fundación Que Todos Pasan Por Alto
- Validación de Solicitudes: Donde La Mayoría de los Errores Realmente Habitan
- Validación de Respuestas: Confía, Pero Verifica
- Gestión de Estado e Idempotencia: El Arte Sutil de la Consistencia
Soy Sarah Chen, y he sido ingeniera de automatización de QA durante los últimos ocho años, los últimos cinco enfocados exclusivamente en pruebas de API para plataformas de fintech y salud. He probado todo, desde simples puntos finales CRUD hasta complejas APIs de procesamiento de pagos que manejan millones de dólares diariamente. Lo que he aprendido es esto: la mayoría de las fallas de API no son casos extremos exóticos; son problemas predecibles que una lista de verificación sistemática habría detectado.
La lista de verificación que comparto hoy es exactamente la que uso para cada punto final que pruebo. Ha salvado a mi equipo de al menos una docena de incidentes de producción solo en el último año, y nos ha ayudado a mantener un tiempo de actividad del 99.97% en más de 230 puntos finales de API. Esto no es teoría, es una realidad probada en batalla de alguien que ha recibido notificaciones a las 3 AM más veces de las que me gustaría recordar.
Autenticación y Autorización: La Fundación Que Todos Pasan Por Alto
Aquí hay una estadística que debería aterrorizarlos: en mi experiencia auditando APIs a través de siete compañías diferentes, aproximadamente el 60% tenía al menos un punto final con lógica de autorización rota. No autenticación, autorización. El punto final verificaba que estabas logueado, pero no comprobaba adecuadamente si debías acceder a ese recurso específico.
Mi lista de verificación de autenticación y autorización comienza con lo obvio, pero a menudo se omite:
- Probar sin token de autenticación en absoluto: debería devolver 401
- Probar con un token expirado: debería devolver 401, no 500
- Probar con un token malformado: debería devolver 401, no fallar
- Probar con un token válido pero con permisos incorrectos: debería devolver 403
- Probar con un token de un usuario diferente tratando de acceder a los recursos de otro usuario
Ese último es donde las cosas se ponen interesantes. Una vez encontré un punto final donde podías recuperar el historial de pagos de cualquier usuario simplemente cambiando el ID de usuario en la URL, a pesar de que estabas autenticado como un usuario diferente. El punto final comprobaba si estabas logueado, pero nunca verificaba si el ID de usuario solicitado coincidía con tu ID de usuario autenticado. Esto se llama Referencia de Objeto Directo Insegura (IDOR), y es sorprendentemente común.
También pruebo flujos de refresco de token explícitamente. ¿Qué sucede cuando un token expira a mitad de una solicitud? ¿Tu API lo maneja con gracia, o deja al cliente en un estado extraño? He visto sistemas donde un token expirado durante una solicitud POST devolvería un 401, pero los datos aún se estaban escribiendo parcialmente en la base de datos. Eso es una pesadilla para la consistencia de datos.
Para APIs que utilizan claves de API en lugar de tokens, verifico que la rotación de claves funcione correctamente. ¿Puedes generar una nueva clave? ¿La antigua deja de funcionar de inmediato o hay un período de gracia? ¿Ese período de gracia está documentado? Una vez trabajé con una API donde la rotación de claves tenía un período de solapamiento de 24 horas que nadie conocía, lo que llevó a fallos en la auditoría de seguridad.
La matriz de autorización es mi arma secreta aquí. Creo una hoja de cálculo con cada punto final en un eje y cada rol de usuario en el otro. Luego, pruebo sistemáticamente cada combinación. Es tedioso, pero ha capturado errores de autorización en el 100% de los proyectos donde lo he aplicado. Sí, 100%. No es exageración; cada proyecto tenía al menos un punto final donde la lógica de autorización era incorrecta para al menos un rol.
Validación de Solicitudes: Donde La Mayoría de los Errores Realmente Habitan
Si tuviera que adivinar dónde se origina el 70% de los errores de API, sería en la validación de solicitudes. Los desarrolladores son criaturas optimistas: escriben código asumiendo que las entradas serán razonables. Pero el internet no es razonable, y tampoco lo son los sistemas que llaman a tus APIs.
Mi lista de verificación de validación de solicitudes es exhaustiva porque necesita serlo:
- Enviar un cuerpo de solicitud completamente vacío: ¿qué pasa?
- Enviar nulo para cada campo requerido individualmente
- Enviar cadenas vacías para campos de cadena
- Enviar cadenas que solo contengan espacios en blanco
- Enviar cadenas que sean un carácter más largas que cualquier límite de longitud
- Enviar cadenas que son 1000 veces más largas
- Enviar números negativos para campos que esperan enteros positivos
- Enviar cero para campos donde cero podría ser inválido
- Enviar números decimales para campos de enteros
- Enviar números extremadamente grandes (probar para desbordamiento de enteros)
- Enviar números extremadamente pequeños (probar para subdesbordamiento)
- Enviar caracteres especiales en campos de cadena: comillas, barras inversas, bytes nulos, Unicode
- Enviar intentos de inyección SQL (incluso si estás usando un ORM)
- Enviar cargas XSS en campos de cadena
- Enviar tipos de datos no coincidentes (cadena donde se esperaba un número, etc.)
Sé lo que estás pensando: "Sarah, eso es una locura. Nadie tiene tiempo para todo eso." Pero—he automatizado toda esta lista de verificación. Tengo un generador de datos de prueba que produce todas estas variaciones automáticamente. La configuración inicial me llevó aproximadamente dos semanas construirla, pero ahora puedo ejecutar todo este conjunto contra un nuevo punto final en aproximadamente 15 minutos.
El beneficio es real. El mes pasado, esta lista de verificación captó un punto final que haría que todo el servidor de API fallara cuando envías una cadena más larga que 65,535 caracteres. El desarrollador había asumido que la base de datos manejaría la validación de longitud, pero la base de datos estaba configurada para truncar silenciosamente, y el código de la aplicación intentaba registrar la cadena completa en un búfer de tamaño fijo. Boom—fallo de segmentación, servidor caído.
Para campos de fecha y hora, tengo una sub-lista de verificación especial porque estos son singularmente terribles:
- Enviar fechas en diferentes formatos (ISO 8601, MM/DD/YYYY, DD/MM/YYYY, etc.)
- Enviar fechas inválidas (30 de febrero, mes 13, día 32)
- Enviar fechas muy antiguas (año 1900, año 1)
- Enviar fechas muy futuras (año 2100, año 9999)
- Enviar fechas con diferentes compensaciones de zona horaria
- Enviar fechas durante las transiciones del horario de verano
- Enviar marcas de tiempo con milisegundos, microsegundos, nanosegundos
Esa de las transición del horario de verano me ha picado dos veces. ¡Dos veces! Pensarías que aprendería, pero es un caso extremo tan extraño que es fácil de olvidar. Ahora tengo una prueba específica que ejecuta transacciones a las 2 AM el día que cambian los relojes, porque es cuando ocurren las cosas extrañas.
Validación de Respuestas: Confía, Pero Verifica
La mayoría de los testers se enfocan mucho en las solicitudes y apenas ven las respuestas. Eso es lo opuesto. Las respuestas de tu API son su contrato con el mundo. Si son inconsistentes, incompletas o incorrectas, has roto ese contrato.
| Categoría de Prueba | Punto de Fallo Común | Respuesta Esperada | Lo Que Realmente Ocurre |
|---|---|---|---|
| Sin Token de Autenticación | Falta de manejo de errores | 401 No Autorizado | 500 Error Interno del Servidor o datos expuestos |
| Token Expirado | Logica de validación de token | 401 No Autorizado | Error 500 o fallos silenciosos |
| Token Malformado | Validación de entrada | 401 No Autorizado | Cierre de aplicación o exposición de traza de pila |
| Token Válido, Permisos Incorrectos | Verificaciones de autorización | 403 Prohibido | 200 OK con acceso a datos no autorizados |
| Formato de Fecha Inválido | Desinfección de entrada | 400 Solicitud Incorrecta | Fallo en la cascada de transacciones |
Mi lista de verificación de validación de respuestas incluye:
- Verificar que el código de estado de la respuesta coincida con el comportamiento documentado
- Verificar que el encabezado content-type de la respuesta sea correcto
- Verificar que la estructura del cuerpo de la respuesta coincida con el esquema
- Verificar que todos los campos documentados estén presentes
- Verificar que no haya campos no documentados (esto importa para la versión de la API)
- Verificar que los tipos de datos de los campos coincidan con la documentación
- Verificar que los valores de los campos estén dentro de los rangos documentados
- Verificar que las marcas de tiempo estén en la zona horaria correcta
- Verificar que los metadatos de paginación sean correctos y consistentes
- Verificar que las respuestas de error incluyan mensajes de error útiles
- Verificar que las respuestas de error incluyan códigos de error para manejo programático
Ese penúltimo punto sobre los mensajes de error es crucial. He visto APIs que devuelven "Error" como todo el mensaje de error. Eso es inútil. Un buen mensaje de error te dice qué salió mal, por qué salió mal, y idealmente qué puedes hacer para solucionarlo. Compara estas dos respuestas de error:
Malo: {"error": "Solicitud inválida"}
Bueno: {"error": "Solicitud inválida", "message": "El campo 'email' es requerido pero no fue provisto", "code": "MISSING_REQUIRED_FIELD", "field": "email"}
El segund...