¿Devuelve un error 401 de una información de pérdida de API?

5

Estoy desarrollando una API para una aplicación en la que estoy trabajando y me he encontrado con una pregunta interesante:

Imagina un punto final de API como este:

GET /customers/123456

que devuelve un solo objeto de cliente. Ahora, en nuestra organización, los clientes pueden pertenecer a organizaciones de ventas. Cada usuario de API está asociado a una organización y quiero restringir el acceso de un usuario a los clientes asociados a su organización.

Entonces, dado un usuario que pertenece a la organización ABC y al cliente 123456 que pertenece a la organización XYZ , ¿qué debería devolver mi API cuando este usuario intente obtener ese cliente?

  • 404 Not Found : si un usuario consulta a un cliente inexistente, devuelve un 404 ya que no se encontró ningún recurso en esa URL.

  • 401 Unauthorized : si consulta un recurso al que no tiene acceso, debería obtener una respuesta "no autorizada".

Me parece que si la API devuelve 401 Unauthorized o clientes existentes de otras organizaciones y 404 Not Found para clientes no existentes, mi API está filtrando información. Por ejemplo, un usuario de la organización ABC podría consultar la API y determinar qué ID de usuario existen y cuáles no.

Notas adicionales:

  1. Las ID de clientes se generan de forma secuencial y no hay espacios vacíos, por lo que el tipo de información que se filtraría sería:

    • ¿cuál será el próximo ID de cliente?
    • ¿cuántos clientes se crearon en un período de tiempo?
  2. Las organizaciones de ventas generalmente están restringidas a áreas geográficas particulares y generalmente no están en competencia directa. Pero algunos territorios se superponen y hay reglas vigentes para regir la "caza furtiva" de los clientes de cada uno. En definitiva, es un entorno ligeramente competitivo en el que realmente no queremos que las organizaciones de ventas sepan sobre los clientes de las demás.

pregunta Kryten 28.06.2018 - 18:35
fuente

1 respuesta

7

En primer lugar, si estas ID de usuario son realmente información confidencial como usted dice, no las coloque directamente en la URL. ¿Por qué no crear URL opacas en su lugar y resolver el problema antes de que ocurra? Si elimina la relación entre la URL y el (los) usuario (s), será casi imposible deducir cualquier relación a partir de un código de estado devuelto.

Por ejemplo, en lugar de:

GET somepath/customers/123456

simplemente implemente algún tipo de pequeño sistema de hash con una tabla de consulta bidireccional y puede usar una URL diferente como:

GET somepath/DC884298C70C41798ABE9052DC69CAEE

Claro, esto requiere un poco más de trabajo, pero si está legítimamente preocupado por el problema, es realmente una implementación trivial.

Volviendo a su pregunta real, el W3C indica que si alguien intenta acceder a un recurso, pero no está debidamente autenticado, entonces está bien devolver 404, en lugar de 403 (Prohibido):

  

Si el servidor no desea que esta información esté disponible para el   cliente, se puede usar el código de estado 404 (No encontrado) en su lugar.

Por la misma lógica, no veo por qué no estaría bien devolver 404 en lugar de 401 si el cliente está autenticado pero no está autorizado. Pero tenga en cuenta que, con este enfoque, alguien que realmente está tratando de trabajar con su API puede confundirse y simplemente asumir que el recurso no existe y no darse cuenta de que simplemente no tiene la autorización suficiente. Esto es en última instancia depende de usted para decidir. Diré que, en mi experiencia, he visto ambos métodos implementados anteriormente. Si eliges devolver un 404, asegúrate de especificarlo en algún lugar de tus documentos API para que otros desarrolladores estén al tanto.

Fuente: enlace

    
respondido por el mertmumtaz 28.06.2018 - 19:16
fuente

Lea otras preguntas en las etiquetas