The Idempotency-Key HTTP header field

Re:The Idempotency-Key HTTP header field by herodoturtle on Sunday July 04, 2021 @04:27PM (#27732354)

Thanks for the insightful comment; makes good sense.

Could you kindly share your view on the security implications of this approach - in particular with reference to the security context outlined in section 5 of the IETF draft:

> For idempotent request handling, the resources MAY make use of the value in the idempotency key to look up a cache or a persistent store for duplicate requests matching the key. If the resource does not validate the value of the idempotency key prior to performing such a lookup, it MAY lead to various forms of security attacks and compromise.

[ Parent | on HN ]

Re:The Idempotency-Key HTTP header field by nivertech on Saturday July 10, 2021 @03:38AM (#27791829)

Yes, that's the case if you use it for unauthenticated users or public API calls.

For that reason I do not support idempotent retries for public API calls.

For the authenitcated users, you cache/store the idempotency keys scoped by the currently authenticated user, i.e:

  {user_id, idempotency_key}

You can add more parts to thie key for better security, i.e.:

  {user_id, api_call_name, idempotency_key}

or even

  {user_id, api_call_name, input_args_hash,  idempotency_key}

etc.

[ Parent | on HN ]