If you’re on this page, chances are you followed a link from a Content-Security-Policy (CSP)-related bug report. This page should help diagnose the offending part of the CSP.
I made this page because I noticed my site breaking browser software, and wanted to fix said software.
What this page demonstrates
This is a test page that demonstrates the following Content-Security-Policy (CSP):
default-src 'none' 'report-sample';img-src 'self';style-src 'sha256-7cS8Hu9ov7dRhfioeeb9J8mtB9/iLLpVIZsMM+BJUcs=' 'report-sample';frame-ancestors 'none';base-uri 'none';form-action https://collector.seirdy.one/webmentions/receive https://seirdy.one/search/;manifest-src 'self';media-src 'self';sandbox allow-same-origin allow-scripts allow-forms;report-uri https://collector.seirdy.one;connect-src https://collector.seirdy.one
Here’s a multi-line version, to reduce horizontal scrolling:
default-src 'none' 'report-sample';
img-src 'self';
style-src 'sha256-HASH' 'report-sample';
frame-ancestors 'none';
base-uri 'none';
form-action https://collector.seirdy.one/webmentions/receive https://seirdy.one/search/;
manifest-src 'self';
media-src 'self';
sandbox allow-same-origin allow-scripts allow-forms;
report-uri https://collector.seirdy.one;
connect-src https://collector.seirdy.one
How to use this page
All pages on my site contain a strict CSP. Most pages on my site have a CSP containing a sandbox
directive that does not specify the allow-scripts
parameter. Here’s the CSP for most of my other pages, such as my homepage:
default-src 'none';
img-src 'self';
style-src 'sha256-HASH';
frame-ancestors 'none';
base-uri 'none';
form-action https://collector.seirdy.one/webmentions/receive https://seirdy.one/search/;
manifest-src 'self';
upgrade-insecure-requests;
sandbox allow-same-origin allow-forms
This page has a CSP that differs in four ways:
- It includes a reporting endpoint
- It specifies an
allow-scripts
parameter on itssandbox
directive - It allows loading media (necessary for the
<audio>
demonstration near the end) - It removes
upgrade-insecure-requests
.note 1
Additionally, I have a 404 page that includes a blank sandbox
directive (i.e., it has no parameters such as allow-same-origin
).
Some browser software breaks upon encountering strict CSPs. It’s difficult to pinpoint whether the offending CSP directive is a fetch directive (default-src
, script-src
, style-src
, etc.), or if it’s the sandbox
directive without allow-scripts
.
Try reproducing the bug on the following pages:
-
This page, but without a
sandbox
CSP directive - This page’s canonical location.
- My homepage
-
This page, but with an empty
sandbox
directive - This page, but with a maximally strict CSP that breaks images, CSS, and more
Note the following:
-
If you can reproduce the bug on all five pages: the offending directives include a fetch directive.
-
If you can reproduce the bug on all pages except the third or fourth: the offending directive is probably a
sandbox
directive’sallow-scripts
orallow-same-origin
parameter, respectively. -
If you can reproduce the bug on the second page but cannot reproduce the bug on the first page, a different missing
sandbox
parameter is probably the culprit. -
If you can only reproduce the fourth and fifth page: the offending directive is
sandbox
withoutallow-same-origin
.
I’m also interested in differences for Firefox users pre- and post- version 128, since this bug was apparently fixed in Firefox 128.
Other places to test
Here are some more sites with very strict CSPs containing sandbox
directives:
If you feel the need to regularly test a specific CSP, I recommend using netcat. In a UNIX-like environment, save this to an executable file and run it:
#!/bin/sh
set -e -u
while true; do echo "\
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Security-Policy: default-src 'none'; frame-ancestors 'none'; base-uri 'none'; form-action 'none'; upgrade-insecure-requests; sandbox
<!DOCTYPE html>
<html><body>poggers</body></html>\
" | nc -l 8000; done
You’ll get a plain page with the specified CSP on port 8000. Edit as you see fit.
Sample elements
The following sections contain demos to see what breaks under a restrictive CSP.
An audio element
I’m adding an <audio>
element to demonstrate how a sandbox
directive breaks WebKit’s media controls. See WebKit bug 237281 for more information.
Eloquence sample audio
Toggle audio transcript
Audio transcript
My primary focus is inclusive design. Specifically, I focus on supporting underrepresented ways to read a page. Not all users load a page in a common web-browser and navigate effortlessly with their eyes and hands. Authors often neglect people who read through accessibility tools, tiny viewports, machine translators, “reading mode” implementations, the Tor network, printouts, hostile networks, and uncommon browsers, to name a few. I list more niches in the conclusion. Compatibility with so many niches sounds far more daunting than it really is: if you only selectively override browser defaults and use plain-old, semantic HTML (POSH), you’ve done half of the work already.
Bugs filed
Let me know if this page helped you discover any new bugs! Here are some bugs that my site has already uncovered:
Bugs I have yet to file:
- Several mobile browsers failing to initialize Reader Mode
- Firefox for iOS failing to perform find-in-page.
Footnotes
-
I removed
Back to reference 1upgrade-insecure-requests
so that my Tor onion service could have the same CSP as this page. The onion service does not support TLS: TLS on onion services is redundant, and no certificate authority offers free .onion certificates.