Results for

Check again2021-11-29 07:41:17 Etc/UTC

Input URL:

Final URL:

The server ( appears to have been located in United States of America during our test.

Please note that some sites use CDNs – content delivery networks – in which case the server location might vary depending on the location of the visitor. This tool is currently on a server in Germany.

Secure connection uses HTTPS by default.

HTTPS encrypts nearly all information sent between a client and a web service. Properly configured, it guarantees three things:

  • Confidentiality. The visitor's connection is encrypted, obscuring URLs, cookies, and other sensitive metadata.
  • Authenticity. The visitor is talking to the "real" website, and not to an impersonator or through a "man-in-the-middle".
  • Integrity. The data sent between the visitor and the website has not been tampered with or modified.

A plain HTTP connection can be easily monitored, modified, and impersonated. Every unencrypted HTTP request reveals information about a user’s behavior, and the interception and tracking of unencrypted browsing has become commonplace.

The goal of the Internet community is to establish encryption as the norm, and to phase out unencrypted connections. See W3C, IETF, IAB. Also:

  • Browsers support HTTP/2 — which improves page loading speeds — only over encrypted connections.
  • Google Chrome (1, 2) and Mozilla Firefox (1) will mark plain HTTP as affirmatively non-secure and make powerful features impossible to use on non-secure sites.
  • Google has begun to favor HTTPS websites in search rankings.

Please note that this tool only checks whether HTTPS is used by default. Next step is to ensure that the server is configured correctly and not susceptible to attacks due to out-of-date software, weak ciphers, etc.

Such things are out of scope for this tool, but Qualys SSL Labs provides an excellent free service that lets you check how a server is doing:

Analyze on SSL Labs

Strict Transport Security not enabled

HTTP Strict Transport Security (HSTS) is a simple and widely supported standard to protect visitors by ensuring that their browsers always connect to a website over HTTPS. HSTS exists to remove the need for the common, insecure practice of redirecting users from http:// to https:// URLs.

When a browser knows that a domain has enabled HSTS, it does two things:

  • Always uses an https:// connection, even when clicking on an http:// link or after typing a domain into the location bar without specifying a protocol.
  • Removes the ability for users to click through warnings about invalid certificates.

Strict Transport Security was proposed in 2009, motivated by Moxie Marlinspike's demonstration of how a hostile network could downgrade visitor connections and exploit insecure redirects. It was quickly adopted by several major web browsers, and finalized as RFC 6797 in 2012.

The basic problem that HSTS solves is that even after a website turns on HTTPS, visitors may still end up trying to connect over plain HTTP. For example:

  • When a user types "" into the URL bar, browsers default to using http://.
  • A user may click on an old link that mistakenly uses an http:// URL.
  • A user’s network may be hostile and actively rewrite https:// links to http://.

In its simplest form, the policy tells a browser to enable HSTS for that exact domain or subdomain, and to remember it for a given number of seconds (the policy is refreshed every time browser sees the header again):

Strict-Transport-Security: max-age=31536000;

In its strongest and recommended form, the HSTS policy includes all subdomains, and indicates a willingness to be "preloaded" into browsers:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Since it's just an HTTP header, HSTS is very easy to add to a domain.

However, to enable HSTS for a domain via the HTTP header, the browser does have to see the header at least once. This means that users are not protected until after their first successful secure connection to a given domain.

To solve the "first visit" problem, the Chrome security team created an "HSTS preload list": a list of domains baked into Chrome that get Strict Transport Security enabled automatically, even for the first visit. Firefox, Safari, and newer versions of Internet Explorer also incorporate Chrome’s HSTS preload list.

The Chrome security team allows anyone to submit their domain to the list, provided it meets a few requirements.

Read more about HSTS and how to configure it in nginx, Apache and IIS.

Referrers leaked

When you click a link, your browser will typically send the HTTP referer [sic] header to the webserver where the destination webpage is at. The header contains the full URL of the page you came from. This lets sites see where traffic comes from. The header is also sent when external resources (such as images, fonts, JS and CSS) are loaded.

The referrer header is privacy nightmare as it allows websites and services to track you across the web and learn about your browsing habits (and thus possibly private, sensitive information), particularly when combined with cookies.

Let's say you're logged in on Facebook. You visit a page with the URL On that page, you click a link to their Facebook page. Your browser then sends Referer: to, along with your Facebook cookies, allowing Facebook to associate your identity with that particular page.

The problem is made worse by the fact that many websites load resources like images and scripts from dozens of third-parties, sending referrer information to all of them, with the typical visitor having no idea that this is happening.

Thanks to a fairly recent development, Referrer Policy, it's finally possible for websites to tell browsers to not leak referrers. It lets you specify a policy that's applied to all links clicked, as well as all other requests generated by the page (images, JS, etc.).

A few different policies are offered, such as origin (strips everything except the origin) and origin-when-cross-origin (sends full URL with same-origin requests, otherwise stripped). We recommend no-referrer, which kills the referrer header entirely for all requests, no matter the destination; or same-origin, which kills the referrer for third-party requests but not for requests to the same origin.

A referrer policy can easily be set with a <meta> element in your HTML. Simply include this inside the <head> section:

<meta name="referrer" content="no-referrer">

While still a work in progress, Referrer Policy is now supported by all major browsers (except Internet Explorer, although it is supported by Edge, the new browser in Windows 10).

Third-party services

The site is loading libraries from one or more CDN:s.

Self-host the files.

The site loads fonts from Google Fonts. While these are hosted on resource-specific domains and no cookies are sent, Google could possibly cross-reference the data (IP and browser fingerprint) with other Google services to identify visitors. Do they? Their own FAQ is vague: "We do log records of the CSS and the font file requests, and access to this data is on a need-to-know basis and kept secure." What "need-to-know basis" means is not explained.

Fonts can easily be self-hosted. The tool google-webfonts-helper lets you select one or more fonts, generates the proper CSS and prepares a zip file with the fonts. For a command-line alternative, the shell script google-font-download provides similar functionality.

First-party cookies

One first-party cookie.

DomainNameValueExpires on
.livingpackets.comcrisp-client%2Fsession%2F115c2c3a-1065-4a45-ac85-76fa58e592a6session_7bedaed5-07d...2022-05-30 19:41:08Z

Third-party cookies

One third-party cookie.

DomainNameValueExpires on
.vimeo.comvuidpl1889356401.1535090...2023-11-29 07:41:08Z

Third-party requests

133 requests (133 secure, 0 insecure) to 20 unique hosts.

A third-party request is a request to a domain that's not or one of its subdomains.

ajax.googleapis.comContent (Google)
d3e54v103j8qbb.cloudfront.netContent (
fonts.googleapis.comContent (Google)
fonts.gstatic.comContent (Google)
player.vimeo.comContent (Vimeo)
i.vimeocdn.comContent (Vimeo)
f.vimeocdn.comContent (Vimeo)
vimeo.comContent (Vimeo)
fresnel.vimeocdn.comContent (Vimeo)

We use Disconnect's open source list of trackers to classify hosts.

Full list of third-party requests:

Content-Security-Policy not enabled

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets. It can also help prevent information leakage. has excellent (free) tools with which you can build or analyze a Content Security Policy.

HTTP headers


Referrer-Policy is a new header that allows a site to control how much information the browser includes with navigations away from a document (or when loading external resources) and should be set by all sites. (It can also be set using a meta element; see above.)


HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS.


X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. This helps to reduce the danger of drive-by downloads. The only valid value for this header is "X-Content-Type-Options: nosniff".


X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking.


X-XSS-Protection sets the configuration for the cross-site scripting filters built into most browsers. The best configuration is "X-XSS-Protection: 1; mode=block".

What this tool checks (and doesn't check)

This tool attempts to simulate what happens when a user visits a specified page with a typical browser. The browser has no addons/extensions installed, and Do Not Track (DNT) is not enabled, since this is the default setting in most browsers.

External files such as images, scripts and CSS are loaded, but the tool performs no interactions with the page — no links are clicked, no forms are submitted.

Disclaimer: The results presented here might not be 100% correct. Bugs happen. This tool is meant to be used by site owners as a starting point for improvements, not as a rigorous analysis.

The HTTP header descriptions are based on the ones from by Scott Helme, CC-BY-SA 4.0. Text about HTTPS partly adapted from the CIO Council's The HTTPS-Only Standard (public domain). MaxMind's GeoLite2 country database (CC-BY-SA 4.0) is used for GeoIP lookups.