| | @@ -1,58 +1,48 @@ |
| 1 | 1 | # The Default Content Security Policy (CSP) |
| 2 | 2 | |
| 3 | 3 | When Fossil’s web interface generates an HTML page, it normally includes |
| 4 | | -a [Content Security Policy][csp] (CSP) in the `<head>`. The CSP defines |
| 5 | | -a “white list” to tell the browser what types of content (HTML, images, |
| 6 | | -CSS, JavaScript...) the document may reference and the sources the |
| 7 | | -browser is allowed to pull and interpret such content from. The aim is to prevent |
| 8 | | -certain classes of [cross-site scripting][xss] (XSS) and code injection |
| 9 | | -attacks. The browser will not pull content types disallowed by the CSP; |
| 10 | | -the CSP also adds restrictions on the types of inline content the |
| 11 | | -browser is allowed to interpret. |
| 12 | | - |
| 13 | | -Fossil has built-in server-side content filtering logic. For example, it |
| 14 | | -purposely breaks `<script>` tags when it finds them in Markdown and |
| 15 | | -Fossil Wiki documents. (But not in [HTML-formatted embedded |
| 16 | | -docs][hfed]!) We also back that with multiple levels of analysis and |
| 17 | | -checks to find and fix content security problems: compile-time static |
| 18 | | -analysis, run-time dynamic analysis, and manual code inspection. Fossil |
| 19 | | -is open source software, so it benefits from the “[many |
| 20 | | -eyeballs][llaw],” limited by the size of its developer community. |
| 21 | | - |
| 22 | | -However, there is a practical limit to the power of server-side |
| 23 | | -filtering and code quality practices. |
| 24 | | - |
| 25 | | -First, there is an endless battle between those looking for clever paths |
| 26 | | -around such barriers and those erecting the barriers. The developers of |
| 27 | | -Fossil are committed to holding up our end of that fight, but this is, |
| 28 | | -to some extent, a reactive posture. It is cold comfort if Fossil’s |
| 29 | | -developers react quickly to a report of code injection — as we do! — if |
| 30 | | -the bad guys learn of it and start exploiting it first. |
| 31 | | - |
| 32 | | -Second, Fossil has purposefully powerful features that are inherently |
| 33 | | -difficult to police from the server side: HTML tags [in wiki](/wiki_rules) |
| 34 | | -and [in Markdown](/md_rules) docs, [TH1 docs](./th1.md), the Admin → |
| 35 | | -Wiki → “Use HTML as wiki markup language” mode, etc. |
| 36 | | - |
| 37 | | -Fossil’s strong default CSP adds client-side filtering as a backstop for |
| 38 | | -all of this. |
| 39 | | - |
| 40 | | -Fossil site administrators can [modify the default CSP](#override), perhaps |
| 41 | | -to add trusted external sources for auxiliary content. But for maximum |
| 42 | | -safety, site developers are encouraged to work within the restrictions |
| 43 | | -imposed by the default CSP and avoid the temptation to relax the CSP |
| 44 | | -unless they fully understand the security implications of what they are |
| 45 | | -doing. |
| 46 | | - |
| 47 | | -[llaw]: https://en.wikipedia.org/wiki/Linus%27s_Law |
| 48 | | - |
| 4 | +a [Content Security Policy][csp] (CSP) in the `<head>`. The CSP specifies |
| 5 | +allowed sources for external resources such as images, |
| 6 | +CSS, javascript, and so froth. |
| 7 | +The purpose of CSP is to provide an extra layer of protection against |
| 8 | +[cross-site scripting][xss] (XSS) and code injection |
| 9 | +attacks. Compatible web browsers will not use external resources unless |
| 10 | +they are specifically allowed by the CSP, which dramatically reduces |
| 11 | +the attack surface of the application. |
| 12 | + |
| 13 | +Fossil does not rely on CSP for security. |
| 14 | +A Fossil server should be secure from attack even with out CSP. |
| 15 | +Fossil includes built-in server-side content filtering logic. |
| 16 | +For example, Fossil purposely breaks `<script>` tags when it finds |
| 17 | +them in Markdown and Fossil Wiki documents. And the Fossil build |
| 18 | +process scans the source code for potential injection vulnerabilities |
| 19 | +and refuses to compile if any problems are found. |
| 20 | +However, CSP provides an additional layer of defense against undetected |
| 21 | +bugs that might lead to a vulnerability. |
| 49 | 22 | |
| 50 | 23 | ## The Default Restrictions |
| 51 | 24 | |
| 52 | | -The Fossil default CSP declares the following content restrictions: |
| 25 | +The default CSP used by Fossil is as follows: |
| 53 | 26 | |
| 27 | +<pre> |
| 28 | + default-src 'self' data:; |
| 29 | + script-src 'self' 'nonce-$nonce'; |
| 30 | + style-src 'self' 'unsafe-inline'; |
| 31 | + img-src *; |
| 32 | +</pre> |
| 33 | + |
| 34 | +The default is recommended for most installations. However, |
| 35 | +the site administrators can overwrite this default DSP using the |
| 36 | +[default-csp setting](/help?cmd=default-csp). For example, |
| 37 | +CSP restrictions can be completely disabled by setting the default-csp to: |
| 38 | + |
| 39 | +<pre> |
| 40 | + default-src *; |
| 41 | +</pre> |
| 42 | + |
| 43 | +The following sections detail the maining of the default CSP setting. |
| 54 | 44 | |
| 55 | 45 | ### <a name="base"></a> default-src 'self' data: |
| 56 | 46 | |
| 57 | 47 | This policy means mixed-origin content isn’t allowed, so you can’t refer |
| 58 | 48 | to resources on other web domains. Browsers will ignore a link like the |
| 59 | 49 | |