I regularly use Wayback Machine to help find archived versions of webpages that have been taken down or are other otherwise unavailable.

While using the site, I noticed a peculiar warning in Google Chrome's address bar.

Chrome - This page is trying to load scripts from unauthenticated sources

Firefox shows a similar warning for insecure scripts.

Firefox -

Should I be concerned that Wayback Machine is trying to load scripts from unauthenticated sources?

(For the record, neither Microsoft Edge or Internet Explorer displayed any warnings)


No, not unless you are using a browser that does not block unauthenticated sources (i.e. plain HTTP) when loading an authenticated source (i.e. HTTPS). Most modern browsers will do this.

The error in this case is:

Mixed Content: The page at 'https://web.archive.org/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://wwwb-sentry.us.archive.org/api/3/store...

As the browser blocked the request, it cannot be intercepted by an eavesdropper or Man-In-The-Middle on the connection, therefore you are safe.

It is likely a configuration error on Wayback Machine sending the request over HTTP instead of HTTPS.


When you see such warnings, you can use the page inspection tool of the Web browser (ctrl-shift-i in Chrome) to analyse the problem.

In Google Chrome, select Security tab in the Inspection window, then reload, then go to the mixed content page (Network tab with a filter "mixed-content:something", like mixed-content:all).

The warning in the Console (in the inspection window) is:

raven.min.js:sourcemap:2 Mixed Content: The page at 'https://web.archive.org/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://wwwb-sentry.us.archive.org/api/3/store/?sentry_version=7&sentry_client=raven-js%2F3.9.1&sentry_key=(sniped)'. This content should also be served over HTTPS.

When I allow that insecure active content, I see two such requests, both HTTP POST to http://wwwb-sentry.us.archive.org/api/3/store/, both with URL parameters and some POST data.

The POST data of the first request is:

{"project":"3","logger":"javascript","platform":"javascript","request":{"headers":{"User-Agent":"Mozilla/5.0 (sniped)"},"url":"https://web.archive.org/"},"exception":{"values":[{"type":"ReferenceError","value":"archive_analytics is not defined","stacktrace":{"frames":[{"filename":"https://web.archive.org/","lineno":21,"colno":36,"function":"?","in_app":true}]}}]},"culprit":"https://web.archive.org/","extra":{"session:duration":17},"event_id":"(snip)"}

This seems caused by the fact that the https://web.archive.org/ page has that script inclusion:

<script src="//archive.org/includes/analytics.js?v=30792cb" type="text/javascript"></script>

The lack of URL scheme in the "//archive.org/includes/analytics.js?v=30792cb" URL means: use whatever scheme was used for load the webpage, here HTTPS. So the URL is really: http://archive.org/includes/analytics.js?v=30792cb which matches ||archive.org^*/analytics.js in the EasyPrivacy blacklist that can be used by many browser extensions available on many browser (AdBlock, ABP, UBlock Origin...).

Indeed, turning off this privacy filtering suppressed that first request. There is still another request:

raven.min.js:2 Mixed Content: The page at 'https://web.archive.org/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://wwwb-sentry.us.archive.org/api/3/store/?sentry_version=7&sentry_client=raven-js%2F3.9.1&sentry_key=(snip)'. This content should also be served over HTTPS.

with POST data:

{"project":"3","logger":"javascript","platform":"javascript","request":{"headers":{"User-Agent":"Mozilla/5.0 (sniped)"},"url":"https://web.archive.org/"},"exception":{"values":[{"type":"Error","value":"only one instance of babel-polyfill is allowed","stacktrace":{"frames":[{"filename":"https://web.archive.org/static/bower_components/wayback-search-js/dist/vendor.9ec7ac6759304bcd4fcb.js","lineno":1,"colno":1,"function":"?","in_app":true},{"filename":"https://web.archive.org/static/bower_components/wayback-search-js/dist/manifest.a780c2be7240369dba64.js","lineno":1,"colno":418,"function":"window.webpackJsonp","in_app":true},{"filename":"https://web.archive.org/static/bower_components/wayback-search-js/dist/manifest.a780c2be7240369dba64.js","lineno":1,"colno":101,"function":"n","in_app":true},{"filename":"https://web.archive.org/static/bower_components/wayback-search-js/dist/vendor.9ec7ac6759304bcd4fcb.js","lineno":1,"colno":1251204,"function":"Object.","in_app":true},{"filename":"https://web.archive.org/static/bower_components/wayback-search-js/dist/manifest.a780c2be7240369dba64.js","lineno":1,"colno":101,"function":"n","in_app":true},{"filename":"https://web.archive.org/static/bower_components/wayback-search-js/dist/vendor.9ec7ac6759304bcd4fcb.js","lineno":1,"colno":248121,"function":"Object.","in_app":true},{"filename":"https://web.archive.org/static/bower_components/wayback-search-js/dist/vendor.9ec7ac6759304bcd4fcb.js","lineno":1,"colno":247664,"function":"Object.","in_app":true}]}}]},"culprit":"https://web.archive.org/static/bower_components/wayback-search-js/dist/vendor.9ec7ac6759304bcd4fcb.js","extra":{"session:duration":393},"event_id":"(snip)"}


I would not assume that you are "fine" because you use one browser or another... there are many variables at play here (no pun intended).

I am not certain if you should be concerned, but this is very interesting question to me. It's good to know that Firefox warns about this, as opposed to the other aforementioned browsers, and there are further steps that you can take to mitigate these types of things...

You could protect yourself from not only this particular potential vulnerability, but many similar other ones (nowadays, browsers are often the best gateways for malware to find it's way into personal computers) by running a couple of browser extensions designed to protect you from these types of attacks, such as NoScript (a must have in my opinion), and HTTPS-Everywhere.

NoScript is specifically designed to stop malacious JS from running before it causes the damage, and HTTPS Everywhere tries to, well... use HTTPS , if available, everywhere. This can help prevent malicious script injection by a MITM attacker. I highly recommend these plugins.

  • Firefox didn't technically show a warning, as I had to click the 🛈 icon to make it appear. Chrome was the only browser to show a unique warning icon. – Steven M. Vascellaro Jul 9 '17 at 3:03
  • All the more reason to use NoScript in that case... interesting. – Chev_603 Jul 9 '17 at 23:38

Generally, I think you should be fine as long as you stick with Chrome and Firefox, as both are blocking the insecure scripts.

  • But the linking of insecure script suggest a serious lack of understanding of the what HTTPS really is (hint: it isn't just HTTP over TLS). – curiousguy Jul 8 '17 at 21:22
  • 1
    This is just plain bad advice... – Chev_603 Jul 8 '17 at 23:08
  • LOL most browsers block unauthenticated sources, so he shouldn't be that concerned... – sxcurity Jul 9 '17 at 2:31
  • The concern is also that the website is (or appears to be) badly coded. – curiousguy Jul 9 '17 at 7:03
  • Oh, I think I may have misunderstood! – sxcurity Jul 9 '17 at 14:28

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.