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.
TOOLBOX
More
Tools.
Website security check
Everything at a glance, with an overall grade
View (German)Security Header Check
Checks HTTPS, HSTS, Content-Security-Policy, clickjacking protection and other headers of your website. With a grade from A+ to F and ready-made configuration.
ViewSSL/TLS Check
Checks the certificate, chain and remaining validity, which TLS versions your server accepts and whether the encryption offers forward secrecy. With a grade and configuration.
View
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.