research/security: what's the most strict CSP that could be applied?

[hpvd]

Since ts-liveview already starts to care for XSS-attacks, in https://github.com/beenotung/ts-liveview

Using JSX, the string values are auto escaped, which helps to prevent XSS from dynamic content.

the next logical step would be to research, how secure it can get via applying the most possible strict CSP (Content security policy)

At this time in the demo https://liveviews.cc/auto-complete, no CSP is set:

tested with https://cspscanner.com/

As a good start, one may use an automatic generator, which are available for many browsers
e.g. https://addons.mozilla.org/en-US/firefox/addon/laboratory-by-mozilla/

[hpvd]

using this browser extension,
the possible/apply-able CSP for the current application (https://liveviews.cc/auto-complete) without breaking it's function would be:

default-src 'none';
connect-src wss://liveviews.cc;
img-src 'self';
script-src 'self' 'unsafe-inline';
style-src 'unsafe-inline' 

the consequence:

[hpvd]

from https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_inline_script

Note: Disallowing inline styles and inline scripts is one of the biggest security wins CSP provides. However, if you absolutely have to use it, there are a few mechanisms that will allow them.

=> with this one should wait what's the architectural decision of moving from ws to http/2 (see #4 (comment) with SSE and fetch #4 (comment))

and then move on, to find a great balance of highest speed and highest security (or maybe both is fully possible... :-)

[hpvd]

for how important this is:

XSS is the most common web application vulnerability. It is in fact the most common cyber vulnerability in general... As evidence - the web accounts for over 50% of all of Google's exploited cybersecurity vulnerabilities, with 35.6% of their exploited attack surface being XSS.

Securing Web Apps with Modern Platform Features (Google I/O ’19)
https://www.youtube.com/watch?v=DDtM9caQ97I&t=209s

[hpvd]

regarding Refactoring inline code (see #8 (comment))

from: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html#refactoring-inline-code

When default-src or script-src* directives are active, CSP by default disables any JavaScript code placed inline in the HTML source, such as this:

<script>
var foo = "314"
<script>

The inline code can be moved to a separate JavaScript file and the code in the page becomes:

<script src="app.js">
</script>

With app.js containing the var foo = "314" code.

The inline code restriction also applies to inline event handlers, so that the following construct will be blocked under CSP:

<button id="button1" onclick="doSomething()">

This should be replaced by addEventListener calls:

document.getElementById("button1").addEventListener('click', doSomething);

[hpvd]

just learned inlining resources like js and css has a second disadvantage:

1. you can't use a strict (=save) CSP, because you have to allow unsave inline or similar (as described above)
2. you can't use browser cache for inlined resources independently: a visitor has to load every inlined resource again
   a) when he/she moves to the next page on the website
   b) when he/she retrurns to the website e.g. after a few days again

Maybe a) isn't fully relevant because the principle of ts liveview if you inline all resources

[hpvd]

=> with this there are 2 good reasons to externalize code: security and speed/serverload/traffic for returning visitors

Does this necessarily lead to speed disadvantage in comparison to inlined code?
No, with http/2 one can use server push to deliver all needed resources at the same time as the first resource (index.html)

here is a great sum up of this topic:
https://www.smashingmagazine.com/2017/04/guide-http2-server-push/

[hpvd]

with this learned, from my pov, it should be possible to apply the most strict and with this the most secure csp rules without sacrificing functionality and performance at all :-)

basic structure of delivery (via http/2):

• pageX.html (as answer to user request)
• globaljs.js (pushed with SSE)
• pageXspecificjs.js (pushed with SSE)
• globalcss.css (pushed with SSE)
• pageXspecificcss.css (pushed with SSE)

too many connection? no, with http/2 the well known connection limit (6 in http/1.1 ) isn't valid any more
https://stackoverflow.com/a/36847527

with this, a strict CSP like this should be possible (rough):

default-src 'none';
script-src 'report-sample' 'self';
connect-src 'self';
img-src 'self';
style-src 'report-sample' 'self';
base-uri 'self';
form-action 'self';
frame-ancestors 'none';
block-all-mixed-content;
report-uri https://my-report-endpoint.com;

of course not everyone can or / would want to use or / need this kind of CSP, but
it would be awesome, if one would not be limited by the base tech itself (ts-liveview)
and could demonstrate this in the demo...

=> What do you think?

[hpvd]

edit of CSP given above, to now fully reach an A+ rating (0 errors, 0 warnings)

[hpvd]

the report-uri is, in the first step, a great help when debugging:

a JSON body will be sent if the content-security-policy blocked a piece of content

since report-sample is activated, you got a sample of the script that was violating the rule...

when there is a strange report, it may also be triggered from a browser extension /addon injecting some code..