Servicios / Evaluaciones técnicas
Evaluación de seguridad de APIs.
Una API expone información y operaciones a aplicaciones, integraciones y distintos tipos de usuario. Evaluamos si cada identidad accede únicamente a los recursos y acciones que le corresponden, y cómo se comportan los controles en los recorridos incluidos en la revisión.
- Superficie
- Recursos, identidades y operaciones
- Preparación
- Documentación y cuentas de prueba
- Resultado
- Escenarios validados y controles a corregir
Cuándo tiene sentido.
Al abrir una API a integraciones o clientes externos, incorporar una aplicación móvil o cambiar el modelo de permisos. La revisión considera quién consume cada operación y con qué identidad.
En plataformas donde distintas organizaciones comparten infraestructura. La separación de datos necesita sostenerse en consultas individuales, listados, exportaciones y acciones administrativas.
Qué se revisa.
Autorización sobre objetos y funciones
La identidad debe tener permiso tanto sobre el recurso solicitado como sobre la acción. Una cuenta que puede consultar un documento no necesariamente puede modificarlo o compartirlo. El conjunto de pruebas se construye con los roles y recursos acordados.
Separación entre organizaciones
Se revisa cómo se obtiene el contexto de organización y dónde se comprueba. El mismo recurso puede aparecer en distintos endpoints, filtros, exportaciones o rutas de descarga. Cada acceso incluido en el alcance necesita conservar el límite entre clientes.
Autenticación y vigencia de accesos
Uso de sesiones o tokens según la arquitectura, cambios de privilegios y revocación. Se evalúan los mecanismos presentes y sus condiciones; distintos tipos de credencial pueden tener políticas diferentes. La revisión registra esa diferencia.
Información devuelta y aceptada
Campos que expone cada respuesta y propiedades que el cliente puede modificar. El contrato documentado se compara con el comportamiento de las operaciones autorizadas, incluyendo errores y diferencias entre roles.
Estados y recorridos
Reglas que vinculan varias operaciones: crear, aprobar, cancelar o reintentar. La documentación de endpoints se complementa con el contexto del proceso. Versiones antiguas y rutas alternativas deben incluirse explícitamente si también se quieren evaluar.
Dos organizaciones, una misma operación
Ejemplo ilustrativo: un operador de A puede descargar un archivo propio. La pregunta de evaluación es qué sucede cuando la operación referencia un archivo de B. El objetivo del control es denegar ese acceso y mantener el uso legítimo de B. El ejemplo requiere datos y cuentas de prueba autorizados.
Comportamiento esperado para operador · organización a
- Consultar un documento de A
- Permitir
- Administrar los permisos de A
- Denegar
- Consultar un documento de B
- Denegar
El rol administrativo de A conserva el límite entre organizaciones. Esta política es ilustrativa: una evaluación contrasta los permisos acordados con el comportamiento real del servidor.
Cómo preparar la evaluación.
- Aportar especificaciones, colecciones de peticiones o ejemplos de uso que correspondan a la versión disponible. Identificar endpoints públicos, autenticados y administrativos.
- Preparar identidades con permisos diferentes y recursos sintéticos propios de cada organización. Definir qué lectura o modificación debería permitirse en cada combinación.
- Identificar restricciones de consumo, dependencias externas y operaciones con efectos persistentes. Acordar cómo se preparan y restauran los datos de prueba.
Qué queda documentado.
Mapa del alcance evaluado: versión, operaciones, roles y recorridos disponibles. La cobertura indica qué pudo comprobarse y qué quedó limitado.
Hallazgos con precondiciones, permisos involucrados, comportamiento observado y efecto sobre los datos o el negocio. La evidencia evita incluir tokens y datos sensibles innecesarios.
Recomendaciones sobre el punto de autorización o validación que necesita modificarse y los comportamientos a comprobar al corregir. Revalidación según la propuesta.
Explorar la muestra del informeCondiciones y límites.
Una lista de endpoints no garantiza que todos los recorridos puedan probarse. La disponibilidad de datos, permisos y dependencias condiciona la profundidad. Los límites de consumo y las pruebas de disponibilidad se coordinan por separado. Una API que utiliza un proveedor externo no autoriza automáticamente la evaluación de ese proveedor.
El alcance final, los accesos y las condiciones comerciales quedan definidos en la propuesta. Podés consultar el recorrido de trabajo y la información para preparar una cotización.
El siguiente paso
Definamos qué necesitás evaluar.
Contanos qué hace tu sistema, qué cambió y qué necesitás conocer. Con ese contexto podemos conversar sobre el alcance.