Web security playground

Mar 24, 2021

View this page in various browsers to observe how they handle different aspects of web security. Most browsers include development tools that will allow you to inspect your browser’s behavior.

Loading this page created the following cookies:

<script>
        document.cookie = "name1=val1; SameSite=Strict";
        document.cookie = "name2=val2; Path=/; SameSite=Strict";
        document.cookie = "name3=val3; Path=/; SameSite=Lax";
        document.cookie = "name4=val4; Path=/; SameSite=None; Secure";
</script>

Reloading this page should cause your browser to submit cookies “name1”, “name2”, “name2”, and “name4”.

This link should cause your browser to submit cookies “name2”, “name3”, and “name4”. The default Path attribute forbids cookie “name1” here.

Selecting this link and then following the “Flyn Computing” link therein back to https://www.flyn.org should cause your browser to submit cookies “name3” and “name4”. The SameSite=Strict attribute causes your browser not to submit cookie “name2” when entering this site from another.

An HTML document that is provided by another web server and that references the image at https://www.flyn.org/projects/VisorFlow/fig-architecture.png should cause your browser to submit cookie “name4”. Your browser will only submit cookies marked with SameSite=None in such a cross-site scenario. See, for example, https://www.cs.uwlax.edu/~wpetullo/web-security.html.

Mixed passive content

The following image is fetched using HTTP. Many browsers will log to their console the presence of mixed passive content, and they might indicate this with a broken security lock.

Source: 
<img src="http://nacl.cr.yp.to/cace-logo-25.png"/>

Mixed active content

The following “script” is fetched using HTTP. Many browsers will refuse to load this mixed active content, and many will log this refusal to their console.


<script src="http://cr.yp.to/"></script>

HTTPS Strict Transport Security

This web server makes use of HTTPS Strict Transport Security. You should find that it provides a Strict-Transport-Security field in its response headers.

Cross-Origin Resource Sharing (CORS)

This page attempts to load WebAssembly code from https://www.aquinas.dev/wasm/busycrate.wasm. This should fail because (1) the domain hosting the code is different than the domain hosting this page and (2) aquinas.dev does not set the Access-Control-Allow-Origin header. A server sets an Access-Control-Allow-Origin header to indicate that its API is meant for use from third-party sites. Many browsers will log to their console the action they take to block these types of requests.

<script>
const go = new Go();
go.argv = [];
WebAssembly.instantiateStreaming(fetch("https://www.aquinas.dev/wasm/busycrate.wasm"), go.importObject).then((result) => {
    go.run(result.instance);
});
</script>

This page also loads JavaScript code from https://api.flyn.org/httpsmtp/wasm_exec.js. The browser allows this because the server at api.flyn.org sets the appropriate CORS header.

<script src="https://api.flyn.org/httpsmtp/wasm_exec.js"></script>

Note that the user could load the code in either of the above cases by clicking on the links. CORS regulates only fetches from JavaScript, WebAssembly, and other dynamic code ran by the browser. The use of a Content-Security-Policy header could further define the sites from which this page could load scripts and other resources.