Discuss your project

TOOLBOX · SECURITY CHECK

Find Mixed Content.

Does your HTTPS page still load content over unencrypted HTTP, and are scripts from third-party servers protected against manipulation? Enter an address, get a grade and see every finding.

The bot check protects the toolbox against automated abuse.

We load the page once, like a browser, and evaluate its HTML code. We do not load embedded files. We do not store results permanently.

WHAT IS CHECKED

One Padlock.
No Gap.

The padlock in the address bar only holds if everything the page loads also comes encrypted. And scripts from third-party servers run with the same rights as your own.

  • 01

    Active Mixed Content

    Scripts, stylesheets, frames, plugin content and form targets over HTTP. Browsers block such requests; without the block, anyone on the network could inject code. A critical finding.

  • 02

    Passive Mixed Content

    Images, icons, audio and video over HTTP. Browsers following the current standard request them over HTTPS or block them, for example with srcset and picture. A warning.

  • 03

    upgrade-insecure-requests

    If your Content-Security-Policy sets this directive, browsers switch all requests to HTTPS. That defuses the findings; the addresses should still be right.

  • 04

    Subresource Integrity

    Scripts and stylesheets from third-party servers with a hash in the integrity attribute: if someone changes the file, the browser does not run it. Plus the coverage: how many third-party files are protected.

  • 05

    integrity and crossorigin

    Only sha256, sha384 and sha512 count; the browser skips md5 and sha1. Third-party files with integrity need crossorigin, otherwise it does not load them at all.

  • 06

    Base Address and Inline Code

    A base address on third-party servers, redirects via meta refresh to HTTP and the number of inline scripts and event handlers as groundwork for a strict CSP.

HOW TO FIX IT

Switch Addresses.
Protect Files.

Ideally, the HTML only contains addresses with https:// or relative addresses. These lines help for the transition and for files from third-party servers.

  • 01

    Switch All Requests to HTTPS

    As a header in the web server configuration. Browsers then request every embedded file over HTTPS. If a target cannot do HTTPS, the file is missing; there is no fallback to HTTP.

    # nginx
    add_header Content-Security-Policy "upgrade-insecure-requests" always;
    
    # Apache (.htaccess or VirtualHost)
    Header always set Content-Security-Policy "upgrade-insecure-requests"
  • 02

    Or Directly in the HTML

    Without access to the server, a meta element in the <head> works too. In observation mode (Content-Security-Policy-Report-Only), the directive has no effect.

    <meta http-equiv="Content-Security-Policy"
          content="upgrade-insecure-requests">
  • 03

    Embed Third-Party Files with SRI

    Embed a fixed version, enter the hash of the file in integrity and add crossorigin="anonymous". If the file differs, the browser does not load it.

    <script src="https://cdn.example.com/library@1.2.3/library.min.js"
            integrity="sha384-HASH-OF-THE-FILE"
            crossorigin="anonymous"></script>
    
    <link rel="stylesheet" href="https://cdn.example.com/style@1.2.3/style.min.css"
          integrity="sha384-HASH-OF-THE-FILE"
          crossorigin="anonymous">
  • 04

    Generate the Hash

    With OpenSSL from exactly the file you checked. The algorithm comes before the value, so sha384- and then the output.

    openssl dgst -sha384 -binary file.js | openssl base64 -A

QUESTIONS

Good to Know.

What is mixed content, and what do browsers do with it?

Mixed content means: a page comes encrypted over HTTPS but loads parts over unencrypted HTTP. Current browsers block scripts, stylesheets, frames and other active content, because anyone on the network could inject code into the page through them. Under the current standard, browsers request images, audio and video over HTTPS themselves and do not load them if that fails; images from srcset or <picture> and addresses with an IP address are blocked right away (W3C Mixed Content, MDN). Older browsers load such content unencrypted. Forms with an HTTP target would send input unencrypted; Chrome warns about this.

What does subresource integrity achieve?

With the integrity attribute, you state the hash of a third-party file, such as a library from a CDN. The browser compares the loaded file with it and does not run it if it differs, for example after an attack on the provider. Only sha256, sha384 and sha512 are valid; the browser skips other values (W3C SRI). Files from third-party servers also need crossorigin="anonymous", otherwise the browser cannot check the hash and does not load them (MDN). Our check does not test whether a hash matches the file, because it does not load third-party files.

How is the grade calculated?

Every check has a weight. Passed counts in full, a warning counts half, a critical finding counts nothing. This gives a value from 0 to 100 and the grade A+ to F. Active mixed content and a page without HTTPS are critical and limit the grade to C at best. If the page sets upgrade-insecure-requests, the browser no longer requests anything unencrypted: active mixed content then counts as a warning, passive as passed. Missing SRI is a warning for files from public CDNs. For services that change their scripts continuously, SRI cannot be used sensibly; that does not count towards the grade.

What does the check not see?

It evaluates the HTML code of the page entered as the server delivers it, at most 1 MB. It does not see content that scripts only load in the browser, addresses in external CSS files or other subpages. It treats content in <noscript> like a browser with JavaScript, so it loads nothing. The developer tools of your browser show all requests of a page; the console also reports blocked mixed content.

Does TOMORIS store my input or the result?

No, not permanently. Our server fetches the page once; the website checked sees our server, not your IP address. The result stays in memory for five minutes so that repeated requests for the same address do not put load on the website again, and it is deleted after six minutes at the latest. Details are in the privacy statement.

YOUR NEXT STEP

You Have the Result.
What Comes Next?

We assess findings, prioritize by risk and put changes into practice on request: as a project with EXPERTS or as ongoing operations with GRID.