Web security playground
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 “distribute” 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:
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.
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.