A user comes (through a link) from a http:// site to another (having different domain) https:// site. We need to track that these two requests are done by the same user. But cookies do not pass over domain boundaries. What to do?

One solution is to add a hash to the URL of the above mentioned link. But this would not be a perfect solution for us. Are there other solutions?

1 Answer 1


The simplest solution for cross-site tracking is to set session information for both domains when the user visits either site. This is normally accomplished with a tracking pixel, which is loaded in the first site as an external resource from the second. The tracking pixel is often a 1 X 1 transparent GIF image generated by a server-side script which simultaneously sets a cookie for the originating site. When both sites use the same protocol (either HTTP or HTTPS), this method works well. Due to various security restrictions, mostly implemented by web browsers, combining the two protocols usually triggers a warning message to the user.

However, this is not the case when the primary page is loaded via HTTP. External resources from secure sites can be loaded into an unencrypted page, including tracking pixels to set cookies for secure sites (barring any software/plugins designed to block such activity), without notifying the user of mixed content. If your users will always visit the unencrypted site first, you can easily set a cookie from the encrypted site on that visit.

The reverse scenario is more difficult, where a user visits the secure site first and must be tracked on the non-secure site. One solution is to deploy server-side code that performs multiple redirects. Given two websites https://example.com and http://foobar.com:

  1. When a user visits https://example.com, the site checks for the existence of its cookie.

  2. If the cookie is not found, the user is redirected to http://example.com, where cookies for both example.com and foobar.com are set in an unencrypted page.

  3. The user is redirected back to https://example.com, where the cookie can be read.

This method works as long as there is basic unencrypted access to example.com. Note that if the Secure flag is not set for a cookie, it can be created over an unencrypted connection and subsequently read over a secure connection.

  • Note that this is also reliant on third-party cookies being enabled in the browser (at least for the site in question).
    – MrWhite
    Commented Mar 20, 2018 at 10:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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