Memory, such a fickle thing, just like the security of websites.

# It began with

Recently, I started on what I thought would be a routine task: deploying my static website on AWS using S3 and CloudFront. But this time, things took an unexpected turn. As soon as the website went live, I noticed something strange. The JS and CSS files, which are crucial for the functionality and look of my site, weren’t loading. I immediately inspected the page, and not really to my surprise, the console was flooded with errors.

The errors were all related to the Content Security Policy (CSP) directives. Messages like “Refused to load the font ‘data:font/woff…’ it violates the following Content Security Policy directive: ‘default-src ‘self’”. Note that ‘font-src’" and “Refused to apply inline style because it violates the following Content Security Policy directive: ‘style-src ‘self’ ‘report-sample’” kept popping up. These issues were not really new to me, but I had a feeling that resolving them wouldn’t be a quick fix.

## What’s CSP?

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.

# First attempt

In my quest to resolve the issue, I turned to the internet for answers. I stumbled upon a handy tool, an extension called Csper. This tool promised to generate a CSP in mere minutes, and it did just that. The policy it generated was quite lengthy, but I was hopeful.

At that point, I thought the issue might be due to missing headers in my HTML. So, I added the generated policy as meta content in my HTML header. After several attempts, it became clear that this approach was not the solution. The problem wasn’t with my HTML, it had to be somewhere else.

# Find the ‘criminal’

I have to say memory is such a fickle thing, I nearly forgot that I added a lambda function to my CloudFront distribution long time ago, which ended up causing a whole lot of unnecessary work. After taking a closer look at my lambda function, I realized it was the culprit, so I set out to rectify it.

Before:

  headers['content-security-policy'] = [

    {
      key: 'Content-Security-Policy',

      value:
        "default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'",

    },

  ];

I updated the value with the content generated by Csper, and it’s working! However, it’s only partially resolved. I still need to deal with inline code.

## Using a hash with CSP

Using a hash is one way to allow the execution of inline scripts in a Content Security Policy (CSP). We can add the hash to our script-src directive to allow it to execute via our Content-Security-Policy header: script-src : 'sha256-***';

# Right tool isnt always right

I used Astro for my website. After rummaging through their documentation, I found a troubleshooting guide to “Refused to execute inline script”: “Solution: Update your CSP to include script-src: 'unsafe-inline' to allow inline scripts to run.” It can’t be helped, I resorted to 'unsafe-hash' and 'unsafe-eval', that being said, my website is still marked as ‘A’ in the security report summary.

## Fix Security Header using Lambda

The reason I added a lambda function to my CloudFront distribution was to fix security header, I typically use a security header scanner to assess the security of my websites. That being said, I failed to add security headers for my application and websites hosted by Amplify.

# Related Discussions

Why is script-src-elem not using values from script-src as a fallback?
Refused to load the font ‘data:font/woff…..‘it violates the following Content Security Policy directive: “default-src ‘self’”. Note that ‘font-src’