Yup, just on the question of putting secrets into get request params vs. headers.
OAuth2 does require SSL, and you're right that both params and headers are equally protected there.
My main concern with putting "secrets" in query strings is that traditionally sensitive data doesn't go in query strings -- it'd be in POST content, normally -- so both browsers and servers are less careful with that data.
Headers DO sometimes contain sensitive data (i.e., standard http auth), so there's a history there, and by default this info would be protected a bit more than GET params, I think.
I do care about the endpoints, for two reasons -- on the server side, a log accidentally containing sensitive data might contain all of the secret tokens for the service, and logs are generally not as carefully protected as, say, the database, so they might be posted for developer review or otherwise exposed.
On the client-side: if a single client is hacked, that's normally just one token exposed (whether it was being passed via header or param, probably). But if the browser simply isn't treating the token as secret data, then it gets around -- addons might send queries out to a server for various contextual features, Google may collect it (to help live search dropdowns), etc. -- it's simply not treated as carefully, so it gets out.
Of course, production uses (vs. developers wandering around) generally wouldn't even be using a browser (and I could personally make sure these params weren't in our logs), so none of this is disastrous; just issues on my mind.
Comments
Yup, just on the question of putting secrets into get request params vs. headers.
OAuth2 does require SSL, and you're right that both params and headers are equally protected there.
My main concern with putting "secrets" in query strings is that traditionally sensitive data doesn't go in query strings -- it'd be in POST content, normally -- so both browsers and servers are less careful with that data.
Headers DO sometimes contain sensitive data (i.e., standard http auth), so there's a history there, and by default this info would be protected a bit more than GET params, I think.
I do care about the endpoints, for two reasons -- on the server side, a log accidentally containing sensitive data might contain all of the secret tokens for the service, and logs are generally not as carefully protected as, say, the database, so they might be posted for developer review or otherwise exposed.
On the client-side: if a single client is hacked, that's normally just one token exposed (whether it was being passed via header or param, probably). But if the browser simply isn't treating the token as secret data, then it gets around -- addons might send queries out to a server for various contextual features, Google may collect it (to help live search dropdowns), etc. -- it's simply not treated as carefully, so it gets out.
Of course, production uses (vs. developers wandering around) generally wouldn't even be using a browser (and I could personally make sure these params weren't in our logs), so none of this is disastrous; just issues on my mind.