How design API URLs to comply with GDPR and OWASP and avoid Personal Identifiable Information in URL-CodePudding

Personal Identifiable Information (PII) should be considered sensitive information and OWASP states that sensitive data should not be part of the URL. https://owasp-aasvs.readthedocs.io/en/latest/requirement-9.1.html

GDPR states that "an online identifier" identifying a person directly or indirectly is PII. https://gdpr.eu/article-4-definitions/

An API providing user preferences where a resource item could look like:

{
  "id": "abc123"           //generated id
  "language": "en_EN",
  "favoriteColor": "BLUE",
  "userId": "[email protected]"
}

Would it then be ok for an API to have a link to this resource?

https://example.com/user-preferences/abc123

From my understanding this would be an example of an indirect online identifier. Does that mean the id needs to be encrypted? And if that is the case - does that mean each encryption of the id (i.e every time a URL is provided from the API) must encrypted with a different salt to avoid introducing a new indirect identifier?

Different URLs for the same resource:

https://example.com/user-preferences/87wytu09ufwc2ercler4ri // abc123 encrypted with salt A
https://example.com/user-preferences/diu4w98iuywfgommbvwdxe // abc123 encrypted with salt B

CodePudding user response：

What we have here is security and compliance requirements having direct impact on our API design. Indeed, it is considered bad practice to put sensitive data into the URLs (reason - every proxy, load balancer, API gateway, web server, ... along the way is allowed to log URLs of incoming requests for debug purposes and we do not want sensitive data to be spread this way). On the other way - doing GET requests ends up being tricky, because we can not put all the stuff we would like to simply into the request body. Parameters of GET requests end up in URL because HTTP and REST is designed this way.

So, what can we do then, to satisfy security and compliance needs? At least two things come to my mind.

Put sensitive data into request headers. They will not end up being part of URL so problem solved.
Solve the problem just how you have proposed to. It is nothing new to the industry. Just follow the path of solving insecure direct object references.

I would go for 1 myself. It is less mysterious than 2 in case of what is going on and how to handle test data.