En un pentest web autorizado, cambiando el ID en /api/orders/1043 ves pedidos de otro usuario. ¿Cómo lo confirmás, reportás y qué recomendás?

Es un IDOR / Broken Object Level Authorization (OWASP API1): el backend autentica, pero no verifica que el objeto pertenezca a quien lo pide.

Confirmación con impacto mínimo:

• Usar dos cuentas de prueba propias (A y B) provistas por el cliente: crear un pedido con B y pedirlo con el token de A.
• Probar todos los verbos, porque GET, PUT, PATCH y DELETE a veces tienen controles distintos. Hacerlo solo sobre objetos de las cuentas de prueba.
• No enumerar IDs masivamente ni descargar datos reales. Si por accidente aparecen datos de clientes, se registra el mínimo necesario como evidencia y se avisa según las RoE.
• Revisar si los IDs son secuenciales, porque eso aumenta la explotabilidad.

Reporte: request y response redactadas, pasos de reproducción, impacto (exposición de PII, posible modificación de pedidos ajenos), severidad CVSS justificada y endpoints afectados. Si expone datos personales en producción, se notifica de inmediato y no se espera al informe final.

Remediación:

• Control de autorización en el servidor, en cada acceso al objeto, y centralizado (middleware o política) para que no dependa de cada desarrollador.
• Filtrar por dueño en la consulta misma:

SELECT * FROM orders WHERE id = ? AND customer_id = ?  -- customer_id sale del token, no del request

• Los UUID dificultan adivinar IDs, pero no reemplazan la autorización.
• Tests automatizados de autorización entre usuarios en CI.
• Detección: logs de accesos denegados y alertas ante un usuario que recorre muchos IDs ajenos.

Proponer UUIDs u ofuscar el ID como solución principal. Demostrar el impacto descargando datos reales de clientes o probar solo GET y dar el endpoint por cubierto.