I have typically implemented password reset functionality by sending a link that included something like this:


On my pwreset page I will typically request a few resources from third parties. From what I understand, since I have sensitive information in my URL at this point, it could be revealed to these third parties in the referer header when the request is made.

While I trust these parties, I would prefer that they don't see URLs that would give them the ability to reset passwords or have this information logged on their end and available should their system be compromised.

A few questions:

  • Is it possible to implement a password reset page that includes third party resources without disclosing the referer?
  • Where else, besides the third party, would this information be visible (if anywhere)?

Yes. This could solve your problem:

  1. mysyte.com/?token=xxx sets a cookie and redirects to mysite.com/changepwd without returning any markup
  2. mysite.com/changepwd recognises the user by the cookie and can safely request for 3rd party resources without leaking the token through referrer headers.

To answer your second question: if the resource is over http, then any network nodes between you and the 3rd party would be able to see the token. If it is https, then it's only the 3rd party that will get the token.

| improve this answer | |

Make the token single-use: expire it when the page is first requested, so it's no longer of any use to anyone after that point should leakage occur.

You can also respond to the initial request with a redirect to a neutral URL which you don't mind being leaked (having set up a cookie/session to remember the authentication). However this still leaves the browser history, server/proxy logs and client-side extensions as possible sources of leakage.

| improve this answer | |
  • Interesting, just to clarify - the token would expire when the user submitted the page for the first time rather than when they requested it, right? – Abe Miessler Oct 6 '14 at 20:38
  • No, the leakage can happen between the initial request and the submission, so the token must expire on initial request. The authorization that token implies can be moved elsewhere, eg to another second-stage token in a hidden input on the form. – bobince Oct 7 '14 at 10:35
  • Interesting, how would you submit the new password request if the token is already expired? – Abe Miessler Oct 7 '14 at 15:16
  • Expiring the link on the initial request can cause problems such as when email scanning systems follow the links and cause them to expire. – SilverlightFox Oct 7 '14 at 19:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.