How to protect your website against XSS
As you develop and publish your website for the public to visit, not only are you seeking viewership. Once you are starting to trend, you could easily get the attention of a hacker. Is your website protected against these top 10 web attacks?
Check them out in this list here.
In today’s article, we will be addressing of the attacks call Cross site scripting (XSS) through the use of Content-Security-Policy (CSP).
Long story short, XSS attack consists of injecting malicious client-side content and scripts into a website. These scripts can then modify how the site looks, and then execute the code provided while loading the page.
One way to address this attack is to use Content-Security Policy. We will go through some details about this CSP, understand how does it protect and what tool can we use to check our own website’s CSP.
Let’s dig in!
What is Content-Security-Policy?
Content-Security-Policy is the name of a HTTP response header that modern browsers use to enhance the security of the document (or web page). The Content-Security-Policy header allows you to restrict how resources such as JavaScript, CSS, or pretty much anything that the browser loads.
What is Content-Security-Policy protecting against?
It is known to protect against Cross Site Scripting (XSS) attacks. But what is XSS
Here is a short video to describe what is it?
If you want to have access to the proper documentation, you can check it out here. It is comprehensive and really easy to understand for beginners.
This also indicates to you the levels associated to each restrictions. Want to be an expert, then lets dive right in.
My own attempt
default-src * 'self';
script-src 'self';
style-src 'self' 'unsafe-inline';
img-src * data: 'self';
font-src * 'self';
connect-src *;
child-src *;
object-src 'self' 'none';
frame-src 'self';
Unsafe
script-src 'unsafe-inline' 'unsafe-eval' 'self' data: https://www.google.com http://www.google-analytics.com/gtm/js https://*.gstatic.com/feedback/ https://ajax.googleapis.com;
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com https://www.google.com;
default-src 'self' * 127.0.0.1 https://[2a00:79e0:1b:2:b466:5fd9:dc72:f00e]/foobar;
img-src https: data:;
child-src data:;
foobar-src 'foobar';
report-uri http://csp.example.com;
script-src should not be allowed to run “data:”
This means the script files are in data format. If you want to run your script files, you should host them and have them loaded from your domain instead. You can trust your own domain since you own it, you can also trust whatever you load from it as well.
report-uri allows you to report attempts to violate content security policy in place. These violation reports consist of JSON documents sent via an HTTP POST request to the specified URI. While report-uri is deprecated, it has been changed to report-to but most browsers have not yet support report-to.
Safe
script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:;
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
report-uri https://csp.example.com;
- script-src => ‘strict-dynamic’
‘strict-dynamic’
The strict-dynamic source expression specifies that the trust explicitly given to a script present in the markup, by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script. At the same time, any allow-list or source expressions such as ‘self’ or ‘unsafe-inline’ are ignored. See script-src for an example.
- script-src => ‘nonce-
’
nonce-base64 value allows you to run unsafe-inline scripts with an exception.
‘nonce-[base64-value]’
An allow-list for specific inline scripts using a cryptographic nonce (number used once). The server must generate a unique nonce value each time it transmits a policy. It is critical to provide an unguessable nonce, as bypassing a resource’s policy is otherwise trivial. See unsafe inline script for an example. Specifying nonce makes a modern browser ignore ‘unsafe-inline’ which could still be set for older browsers without nonce support.
- script-src => ‘self’ ‘unsafe-eval’
‘self’
Refers to the origin from which the protected document is being served, including the same URL scheme and port number. You must include the single quotes. Some browsers specifically exclude blob and filesystem from source directives. Sites needing to allow these content types can specify them using the Data attribute.
This is important and also frequently used to indicate that you want to run script files that comes from your own domain in which the document was served. For example, if i am loading a page from phuaxueyong.com. With script-src: ‘self’, this page is only allowed to load any script files that comes from phuaxueyong.com.
‘unsafe-eval’
Allows the use of eval() and similar methods for creating code from strings. You must include the single quotes.
eval() is a browser function that allows you to run strings as code to be executed.
Check your own website’s security policy
Google allows you to test and check your content security policies of any website over here.
You can use this to figure out which policy are you lacking and what you can add onto your own website to better protect against XSS.
TLDR;
As we start to embrace the online platforms, and web-based solutions, we have to keep ourselves abreast with the threat that comes with these tools. Recognising the threat is the first step to mitigate them. Technology as a strength can also create new weaknesses for you.