belgif
Avoiding personal information in URLs
Discuss and elaborate alternatives for putting sensitive data in URLs
Related OWASP:
- https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url
- https://cwe.mitre.org/data/definitions/598.html
other sources:
- https://support.google.com/adsense/answer/6156630?hl=en
- https://salocin-group.com/edit/insights/how-to-make-sure-your-urls-are-data-compliant/
From Belgif REST security draft (it was never discussed/validated by the WG):
To avoid leaking potentially sensitive information in the URL, GET and DELETE requests SHOULD be converted to POST and the original HTTP method appended to the URL (e.g., GET /employers/93017373 becomes POST /employers/get).
Though this design doesn't seem to be very complete:
- how to differentiate get on individual resource from consult of collection with filter params?
- impact on other guidelines: linking with "href", ETag/caching, ...
Pseudonymization of values might be an alternative, but is probably too complex as a general solution for all possible use cases.
Referer Header, Browser History, Browser Cache, Shoulder Surfing -> these mostly seem like webapp / browser concerns?
Does this security risk really apply to business-to-business REST API calls over HTTPS? URLs are encrypted when using HTTPS, right?
Web logs (a.k.a. access logs) is still applicable. The URLs are indeed encrypted, but the risk is about what happens beyond the TLS endpoints. Access logs are typically made by shared infra like reverse proxies, api gateways etcetera, that are outside of the control of the client or server application, which makes concerns like data access control and retention more difficult to manage.