Sensitive information in QUERY URLs

[martinthomson]

          I'm looking for an additional qualification on the statement, something like:

If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content-Location field), the URI of this resource &SHOULD-NOT; expose any sensitive information from the original request content in plaintext.

Originally posted by @martinthomson in #2851 (comment)

[martinthomson]

@reschke also suggested a reframing to "SHOULD":

maybe... "... the URI SHOULD be chosen in a way that potentially sensitive information is not exposed."?

Originally posted by @reschke in #2851 (comment)

(Also, should we rename the "safe-method-w-body" label to "query-method", now that that naming thing is settled. It took me a while to remember the right label.)

[MikeBishop]

I'm not confident that implementers will always know what might be sensitive and probably should not expose any of the payload in the URL. I think the qualifier doesn't reduce the suggestion's practical scope at all, so if it gets us to consensus, let's add it.

[martinthomson]

I'm less concerned about this ending up in logs than you are, it seems :) For me, the risk that a server log might have sensitive information is already at 100%, which means that log processing needs to include considerable care as far as privacy and security risks go.

[reschke]

Both variants work for me, and IMHO are better than what we have now.

Mike, pick one :-)

[nicowilliams]

Query media types could evolve whose syntax allows for specification of elements that the user/user-agent considers "sensitive", and also the server could know from the schema of the underlying data. But really I think a big hammer is needed here:

• the default should be that servers encode none of the query contents into the resulting Location
• user-agents should be able to request that behavior with a request header (e.g., Query-Sentitive: true)

But user-agents should also be able to request that the resulting Location encode as much as possible of the QUERY request body so that the user can end up having a URI that can form part of the UI. This should be completely OPTIONAL as far as the server is concerned, and will not always be possible due to URI length constraints and/or the difficulty of encoding complex queries in URI local-parts and q-params.

[reschke]

I believe that should be completely up to the server.

[MikeBishop]

I'm inclined to agree with Julian here. From the client's perspective, the server is a monolith -- in the course of handling the request, the server necessarily sees the contents and the data (multi-party compute schemes notwithstanding) and the client trusts it to do so according to whatever privacy policy exists. It's the server operator's issue whether they wish to keep certain information out of their logs in order to reduce how tightly access to their logs must be managed.

Plus, it's implementation guidance at this point, not protocol conformance. We point out the concern and let people in the real world figure out how they navigate it.

[nicowilliams]

An optional header by which the client can request a URI that encodes the query (which may not be feasible, but often will be) vs. not, seems like a good idea to me -- the server doesn't have to grant the client's wish, but having this request header specified will result in better usability. (To go with this an optional response header by which to indicate which option the server went with would be nice.)