Cómo probar los permisos de una API de archivos: recursos, acciones y casos negativos

Una guía para planificar, no el contrato de una API

La autenticación y la autorización responden a preguntas distintas. La autenticación se refiere a quién presenta una solicitud; la autorización, a si esa identidad puede realizar una acción. La distinción ayuda a organizar una revisión, pero no indica por sí sola qué permisos, recursos o respuestas admite una API de archivos concreta.

Por eso, trata los ejemplos de esta guía como ideas de planificación y no como comportamientos verificados de un servicio. Antes de preparar casos, consulta la documentación primaria y la configuración aplicable. Ahí debes buscar las operaciones disponibles, los requisitos de autenticación y los criterios que permitan determinar qué resultado se espera. No deduzcas rutas, roles, propiedad de archivos ni códigos de respuesta por analogía con otras API.

Las referencias a productos específicos tampoco son reglas universales. Microsoft documenta ApiCenterMinimalPermissionsPlugin como una herramienta para comprobar si una aplicación llama a las API con permisos mínimos ([Microsoft Learn](https://learn.microsoft.com/es-es/microsoft-cloud/dev/dev-proxy/how-to/check-minimal-api-permissions)). En el caso de Google Drive, su documentación indica que se deben declarar los permisos que necesita la aplicación en la configuración de consentimiento de OAuth ([Google for Developers](https://developers.google.com/workspace/drive/api/guides/api-specific-auth?hl=es-419)). Ninguna de esas referencias define cómo funciona otra API.

• Separa las ideas generales de prueba de las capacidades confirmadas para el servicio que integras.
• Usa la documentación del producto y la configuración vigente para establecer los resultados esperados.
• No traslades a otra API los permisos, las herramientas o los flujos de Microsoft o Google.

Define el alcance antes de preparar casos

Empieza por delimitar qué quieres validar. Anota qué identidades de prueba tienes autorizadas, qué recursos de ensayo están disponibles y qué operaciones aparecen en la documentación. El objetivo no es completar una matriz hipotética, sino convertir requisitos verificables en preguntas de prueba concretas.

Para cada operación que realmente vayas a evaluar, registra las precondiciones relevantes y la fuente del criterio esperado: por ejemplo, una sección de la documentación o una configuración del servicio. Si todavía no puedes explicar por qué una identidad debería poder realizar la acción, marca el criterio como pendiente en lugar de presentarlo como un hecho.

No presupongas que el servicio define un archivo «propio» ni que organiza el acceso mediante roles, grupos o enlaces. Si esos conceptos aparecen documentados, utiliza sus definiciones exactas. Si no aparecen, evita inventarlos para llenar el plan. Una descripción precisa de lo desconocido es más útil que una regla supuesta.

• Registra la identidad lógica de prueba, el recurso, la acción y sus precondiciones.
• Relaciona cada resultado esperado con una fuente verificable.
• Deja explícitos los puntos que la documentación no resuelve, sin convertirlos en requisitos.

Diseña casos que respondan a preguntas concretas

Una planificación útil vincula cada caso con una pregunta acotada: ¿qué requisito se está comprobando?, ¿qué condición se mantiene?, ¿qué resultado permitiría confirmar o refutar el criterio? Esta estructura ayuda a distinguir una prueba informativa de una petición que solo produce una respuesta sin contexto.

Cuando el contrato de la API describa operaciones distintas, evalúalas por separado. Un resultado observado para una operación no demuestra automáticamente qué ocurriría con otra. De igual modo, no clasifiques un caso como permitido o denegado si no tienes una base documentada para esa expectativa.

Si quieres comparar dos condiciones, cambia una sola variable cuando el diseño de la API y el entorno permitan hacerlo. Así podrás atribuir con más claridad cualquier diferencia observada. Esta es una recomendación general de planificación; no presupone que la API utilice una estructura determinada ni que admita todos los ensayos.

Mantén diferenciados los resultados esperados y los observados. Si la API responde de una manera que la documentación no anticipa, registra la diferencia y la fuente consultada. No conviertas automáticamente una respuesta concreta en criterio de aprobación o fallo cuando el contrato no especifica ese comportamiento.

• Formula una pregunta verificable para cada caso.
• Distingue operaciones y condiciones, en vez de extrapolar un resultado a toda la API.
• Anota cualquier ambigüedad del contrato como una cuestión abierta.

Ejemplo condicionado: probar con otro identificador

Si la documentación describe solicitudes que identifican recursos, y el entorno permite probarlas, puedes plantear un ensayo controlado con un recurso de prueba diferente. La pregunta sería si el resultado observado coincide con el criterio que establecen la documentación y la configuración. Este ejemplo no afirma que todas las API usen identificadores ni que compartan un comportamiento de autorización.

Antes de ejecutar el ensayo, confirma que tienes autorización y que los recursos son adecuados para pruebas. Define de antemano qué información necesitas observar y evita hacer cambios que no formen parte del caso. Si la operación podría modificar contenido, comprueba después el estado del recurso mediante un método permitido por el servicio y registra solo la evidencia necesaria.

No uses un identificador ajeno o datos privados para sustituir un entorno de prueba. Tampoco interpretes una respuesta genérica como prueba de una política concreta si el contrato no permite esa conclusión. Cuando el comportamiento esperado no esté descrito, el resultado correcto del trabajo puede ser documentar la duda y solicitar una aclaración.

• Realiza el ensayo solo con credenciales y recursos autorizados.
• Usa identificadores de prueba únicamente si la API y el entorno permiten ese tipo de comprobación.
• Compara lo observado con el criterio documentado, no con una suposición.

Documenta resultados que otra persona pueda revisar

Un registro claro permite entender qué se comprobó sin depender de la memoria de quien ejecutó la prueba. Para cada caso, conserva una fecha, una identidad lógica de prueba, el recurso de ensayo, la acción, las precondiciones y el resultado esperado y observado. Añade la referencia documental que justifica el criterio.

Si guardas solicitudes, respuestas o capturas, revisa su contenido antes de compartirlas. Oculta credenciales, tokens y otros secretos, y evita incluir información privada que no haga falta para explicar el resultado. Cuando el cuerpo de una respuesta no sea necesario, conserva una descripción o un extracto redactado en vez de copiarlo completo.

Separa los hechos observados de las interpretaciones. Por ejemplo, registra qué respuesta se recibió y, en otro campo, si coincide con lo que describe el contrato. Si la documentación no resuelve una diferencia, anótala como cuestión pendiente y dirígela al proveedor o al responsable técnico.

• Incluye el criterio y su fuente junto al resultado de cada caso.
• Enmascara secretos y limita las evidencias a lo necesario para la revisión.
• Distingue observaciones, conclusiones y preguntas aún sin resolver.

Relaciona la revisión con las capacidades de Apification

El catálogo de Apification indica que Cloud permite proteger archivos y servicios con permisos, OTP, autenticación externa, restricciones y ventanas de publicación. También describe el uso compartido mediante enlaces, usuarios o grupos. Estas capacidades sirven para identificar temas que podrían ser relevantes al revisar una configuración de Cloud, pero no especifican por sí mismas un modelo de autorización para una API ni el resultado de una solicitud concreta.

El catálogo también indica que Cloud y sus servicios se pueden integrar mediante API REST, OpenAPI, webhooks, iframe y JavaScript. Esa descripción confirma opciones de integración a nivel de producto, pero no proporciona aquí endpoints, parámetros ni respuestas esperadas. Para implementarlas o diseñar pruebas contra un servicio específico, consulta la documentación aplicable.

Mantén esa separación en tus conclusiones: puedes describir las capacidades que el catálogo confirma y, por otro lado, señalar qué detalles de autorización no están especificados en la información disponible. Así evitas prometer compatibilidad o comportamientos que todavía requieren verificación.

• Usa el catálogo para reconocer capacidades de producto, no para inferir detalles de endpoints.
• Consulta documentación específica antes de traducir una capacidad en un caso de integración.
• Expón con claridad cualquier detalle de autorización que siga sin verificarse.

Cierra la revisión con una lista de verificación

Antes de integrar o de compartir resultados, revisa que el alcance sea comprensible para otra persona y que los criterios estén respaldados. Si una prueba no puede ejecutarse de forma autorizada o no tiene un resultado esperado justificable, no la presentes como una comprobación concluyente.

La lista siguiente sirve como control editorial del plan. No sustituye la documentación del servicio, no garantiza un resultado de seguridad y no define respuestas comunes para todas las API. Su propósito es ayudar a detectar suposiciones y evidencias incompletas antes de tomar decisiones de integración.

• ¿Cada operación evaluada está descrita para la API concreta?
• ¿Los resultados esperados se apoyan en documentación o configuración verificable?
• ¿Se distinguen los resultados observados de las conclusiones?
• ¿Las pruebas se limitan a recursos y credenciales autorizados?
• ¿Se eliminaron secretos y datos privados de las evidencias?
• ¿Las dudas pendientes están identificadas en vez de resolverse mediante suposiciones?

Preguntas frecuentes