diff --git a/sections/designRules.md b/sections/designRules.md index 4b50037..fcfee1f 100644 --- a/sections/designRules.md +++ b/sections/designRules.md @@ -745,9 +745,17 @@ Note: security controls for signing and encrypting of application level messages
Even when using TLS connections, information in URIs is not secured. URIs can be cached and logged outside of the servers controlled by clients and servers. Any information contained in them should therefore be considered readable by anyone with access to the network (in the case of the internet, the whole world) and MUST NOT contain any sensitive information. This includes client secrets used for authentication, privacy sensitive information such as BSNs or any other information which should not be shared. +
When using TLS connections, the path and query information in URIs are secured just like the message headers and body. However, URIs can be cached and logged, as can headers and bodies in the following situations: +
For REST API's that are accessed directly from user devices, like web browsers, do not put client secrets used for authentication and other sensitive information in the URI. These are directly visible to users, are stored in the web browser's history and cache and can be bookmarked and sent to others. +
For REST API's that are only used for system-to-system interation on closed networks where all systems are under control of the involved client and server organisations, do not put client secrets used for authentication in the URI and be careful to put sensitive information in the URI. Intermediate network components that terminate and newly initiate TLS could log or otherwise store URIs. Consider the consequences, advantages and disadvantages of using sensitive information in the URI and be deliberate about which information is logged, for which purposes and who has access.
Be aware that queries (anything after the '?' in a URI) are also part of a URI.
The term sensitive is deliberately left undefined in this document.