Auth tokens are exposed?

Tech
1

I was reading the Beeminder API documentation, and saw the auth tokens are appended to the URL as a query parameter, e.g. https://www.beeminder.com/api/v1/users/alice/goals/myGoal.json?auth_token=abc123. This is fine if the token does not grant write access to user data, but I can also see that the same auth token is used for POST/PUT requests like updating or creating goals.

e.g.

curl -X PUT https://www.beeminder.com/api/v1/users/alice/goals/exercise.json \
    -d auth_token=abc124 \
    -d title=Work+Out+Even+More \
    -d secret=true

Isn’t this insecure because I can look at these public query parameters and make malicious requests on behalf of the victim? Or, did I understand something wrong?

1 Like
2

I believe you are correct. These days tokens can be sent in the auth headers instead.

1 Like
3

Query parameters are no more or less public or private than headers are. Given that your request is over HTTPS, nobody along the way can read either the headers or the query parameters.

The one way in which query parameters might be considered less private is via norms about logging and so forth; many logging frameworks log all query parameters automatically, and need to be configured to not log sensitive ones. Likewise, if you were to visit such a URL in your browser, by default the query parameters would be stored as part of your browser history.

To the extent that you’re using curl, both the headers and the query parameters would be logged in your shell history to the same extent.

If you really want, feel free to send the auth token in the headers, which also works. But be aware that there is nothing intrinsically insecure about sending the auth token in the query parameters.

2 Likes
4

Thanks. I understand that it is not as pubic as I thought. However, it’s still definitely a much better practice to have it in the header for the reasons you also mentioned regarding logging. I hope the Beeminder team improves this.

To the extent that you’re using curl

That was just an example.

If you really want, feel free to send the auth token in the headers

Great, I’d probably do that.

1 Like
5

Sounds like updating the docs and its examples could be an easy way to put most people on a better track, since using headers is already supported

6

Which header did you use to send the auth token? I tried it as a GET request, but it does not work?

I tried auth_token, X-auth_token, Authrization, etc.

7

As it says in the docs, use the Authorization header with a Bearer scheme.

So it’s Authorization, not Authrization, and prefix your token with the word Bearer and a space. With curl, that might look like curl -H "Authorization: Bearer $AUTH_TOKEN".