REST: Best way to deal with secrets in DELETE

Question

I need to use a sensitive value as primary identifier in a REST Api.

This would be identified as: DELETE /api/sometoken/<sensitiveid>

Since sensitive data should not be included in URLs, I wonder what the best option is.

Sensitive ID in body

Would it be a valid solution to set the id as json in the body? This would result in DELETE /api/sometoken with body { "id": "<sensitiveid>" }

I am not sure if this is ok, since DELETE does not directly reference an entity by url.

Abuse POST

Alternatively, I could use POST instead of DELETE, and contain the information about delete in the body or url. I assume this would be even worse.

Abstract ID

This most complex solution would probably be using a different id. When using GET, to lookup the all sensitive ids for my subscription and then DELETE the abstract id.

Hashed ID

I thought of making an sha-256 hash and taking the first n characters to id identify the sensitive token.

DELETE /api/sometoken/<hashofsensitiveid>

You can send the sensitive id in the entity body of the DELETE request: https://stackoverflow.com/a/10015724/1802536 — Silvanu, Nov 20 '21 at 22:23
Using a non-sensitive id in your URLs sound like a smart way to deal with this. A hash especially sounds smart. — Evert, Nov 21 '21 at 20:20

score 0 · Answer 1 · answered Nov 21 '21 at 18:20

0

Putting secrets in the body part of the request is usually a good idea, but there might be issues for GET and PUT requests: Is an entity body allowed for an HTTP DELETE request?

If it is sensitive and should not appear in some web server or traffic logs - make it simply a header.

answered Nov 21 '21 at 18:20

Marek Puchalski

3,286
2
26
35

1

The top answer there is wrong, you should not use bodies with `DELETE` requests. – Evert Nov 21 '21 at 20:16

REST: Best way to deal with secrets in DELETE

Sensitive ID in body

Abuse POST

Abstract ID

Hashed ID

1 Answers1