Cross-Site Scripting (XSS) is a type of attack where malicious code is injected into a website and executed on the visitor's browser. Code injection was the third most widespread category of vulnerabilities in web applications in 2021.¹

It usually follows this pattern:

1. The attacker crafts malicious HTML tags or JavaScript code.
2. The attacker injects the code into any input the website has.
3. The website serves its contents (including the malicious code).
4. The visitor's browser executes the malicious code.

The input could be any kind of form or file upload functionality, as well as external scripts and media integrations. The key point is that the website has to serve you content outside its own control.

Implementing policies to improve security§

The first thing to do in order to improve the security of your site is to re-evaluate if it really has to be a dynamic site. Converting your site to a static one reduces the attack surface massively, but this is not enough (and cannot be considered a security measure by itself).

Content Security Policy§

Regardless of the kind of site you have, you need to control which resources your visitor's browser is allowed to load for any given page. Luckily for us, there is an HTTP header for exactly that purpose: “CSP” or “Content Security Policy”.

Here, we will be explaining a very basic, but powerful CSP, which will be very generic and restrictive. That way, for most people (especially those who use static sites) will be enough. If, for any reason, you would need a finer-grain control, I encourage you to consult the wonderful documentation about CSP² available at Mozilla Developer Network.

The syntax of a CSP header is: Content-Security-Policy: <policy-directive>; <policy-directive>

• Content-Security-Policy: the name of the header
• : to indicate a list of policies follows the colon mark
• <policy-directive>: name and values of the directive
• ; to indicate more policies are specified
• <policy-directive>: name and values of more directives

All the directives fall into 4 categories: fetch, document, navigation and reporting.

• Fetch directives: control the locations from which certain resource types may be loaded. Could be fonts, images, media, scripts, styles, etc...
• Document directives: control the properties of a document or the environment to which a policy applies.
• Navigation directives: control which locations a user can navigate to.
• Reporting directives: control the destination URL for CSP violation reports.

The simple yet restrictive CSP this blog follows is the following:

Content-Security-Policy: default-src 'self' *.lightningwright.net lightningwright.net; frame-ancestors 'none'; base-uri 'none';

• default-src: serves as a fallback, so any kind of content follows this rule unless otherwise stated.
  • 'self': only allows resources from the current origin.
  • *.domain: allows resources from any subdomain
  • domain: allows resources from this domain
• frame-ancestors: specifies valid parents that may embed a page. Prevents clickjacking.
  • 'none': no site is allowed
• base-uri: restricts which URIs can be set with an HTML tag
  • 'none': no URI is allowed

Fixing CSP-related issues§

After adding a CSP header, things may break. Expect to tweak the previous policy to meet your needs. In my case, syntax highlighting stopped working. I originally set up "Zola" (the static site generator this blog uses) to generate inline styles for all code blocks. This conflicts with the CSP, which prohibits any inline code within the HTML tags.

I initially tried to allow HTML inline styles, but that defeats the purpose of CSP, so I had to change the way styles are generated for syntax highlighting. Looking at the Zola documentation³, there is a section that explains how to tell the generator to use CSS styles. In your site configuration file config.toml you have to change your syntax highlighting theme highlight_theme = "yourtheme" to the following:

highlight_theme = "css"
highlight_themes_css = [
    { theme = "yourtheme", filename = "assets/yourtheme.css" },
]

There is no need to specify the assets folder, but I like to keep things organized. Also, change yourtheme to your custom theme.

If you reload the site, your styles won't work yet. That is because you still have to import this new CSS file into the <head> section of the generated HTML or use an import directive in CSS like the following:

@import url("assets/yourtheme.css");

Cross-Origin Resource Policy§

Another opt-in policy that can be set with an HTTP header is Cross-Origin Resource Policy (CORP). This policy prevents loading resources such as <script> from unknown or unwanted origins.

The only valid options that can be specified in this policy are:

• same-site: only accepts requests from the same Site. Use this if you need to load resources from subdomains.
  • A site is defined by its eTLD and eTLD+1.
    • Examples of eTLD are: .net, .com or even github.io. All defined in the Public Suffix List
    • eTLD+1 is defined as the part of the URL immediately preceding the eTLD
• same-origin: only accepts requests from URLs using the same scheme (https, http), host name, and port (even if implicit).
• cross-origin: which defeats the purpose of this policy unless COEP⁴ is used.

For flexibility, I use: Cross-Origin-Resource-Policy same-site.

If you want a more restrictive one, expect to tweak your server settings and/or affected web applications.

MIME type verification§

MIME types describe remote content format. If a browser is not able to detect content types, it may not enforce security policies correctly and end up loading unwanted or malicious files.

The header X-Content-Type-Options with value: nosniff tells the browser to block any request whose content does not match the correct MIME type.

• CSS style sheets (content of type style) must have text/css as the MIME type.
• Attached images, whether GIF, PNG, or JPEG XL, must have image/gif, image/png and image/jxl respectively. Note that JPEG XL is a relatively new format, and some systems might not recognize it yet. application/octet-stream MIME type might be used as a fallback.
• Scripts loaded with a script mark must have text/javascript or any of the legacy JavaScript MIME types.⁵

Bonus: Referrers§

By default, if your site loads resources from external domains, the visitor's browser will send an HTTP GET request with an additional header, the Referer header. Yes, it is a misspelling of the word "referrer".

It informs the destination site of the origin of the request. This is a very useful feature in case the administrator of the destination site has to rate limit certain network traffic sources. A sudden increase in a website's traffic is almost never well-intentioned, so we cannot assume that this information will be used fairly.

In order to improve the privacy of your visitor, it is better to tell their browser to not send that information with the following header: Referrer-Policy: no-referrer

To keep your privacy, you have to proactively seek it. No single measure or configuration will prevent all sorts of risks. That said, these measures cover up one of the most exploited vulnerabilities in web development, and, as a bonus, your visitors will stop broadcasting that they visited your site to any external domain you decide to link (social networks, online stores, etc.).

Update Web Server/App Headers§

Now that we have covered some essential security headers, let's update the web server configuration to put them into action.

Caddy§

If you use Caddy as a web server, Caddyfile needs to be edited. For convenience, you can add each header to a snippet and then import it into each domain you want them to be applied:

(header-policies) {
	header {
		Cross-Origin-Resource-Policy same-site
		# more headers...
	}
}
yourdomain.com {
    # domain settings...
    import header-policies
}

NGINX§

If you use NGINX as a web server, edit nginx.conf (or your custom .conf file). You must add each header inside a server block, following the syntax below:

server {
# server definitions...
add_header Cross-Origin-Resource-Policy "same-site";
# more headers...
}

Check your final configuration§

Finally, to verify the policies that have been modified, we can use this amazing tool created by Mozilla: the HTTP Observatory.⁶

This online tool scans your site and analyzes all security-relevant headers in order to generate a report highlighting any potential issues or missing settings. It also suggests and explains more policies that may apply to your site, if necessary.

I hope you found this post useful. Have a nice day.