Receive AccessDenied when trying to access a page via the full url on my website

Question

For a while, I was simply storing the contents of my website in a s3 bucket and could access all pages via the full url just fine. I wanted to make my website more secure by adding an SSL so I created a CloudFront Distribution to point to my s3 bucket.

The site will load just fine, but if the user tries to refresh the page or if they try to access a page using the full url (i.e., www.example.com/home), they will receive an AccessDenied page.

I have a policy on my s3 bucket that restricts access to only the Origin Access Identity and index.html is set as my domain root object.

I am not understanding what I am missing.

To demo, feel free to visit my site.

You will notice how it redirects you to kurtking.me/home. To reproduce the error, try refreshing the page or access a page via full URL (i.e., kurtking.me/life)

Any help is much appreciated as I have been trying to wrap my head around this and search for answers for a few days now.

8.27.2023 Disclaimer

The solution I marked as the answer worked for me at the time, and held me over as I was developing locally and learning. It has come to my attention that this may not be the best practice.

I have not spent enough time in this area of AWS to have a recommended alternative, but some ideas are floating throughout the Answer section.

Answer 1

I have figured it out and wanted to post my solution in case anyone else runs into this issue.

The issue was due to Angular being a SPA (Single Page App) and me using an S3 bucket to store it. When you try to go to a specific page via url access, CloudFront will take (for example, /about) and go to your S3 bucket looking for that file. Because Angular is a SPA, that file doesn't technically exist in your S3 bucket. This is why I was getting the error.

What I needed to do to fix it

If you open your distribution in Cloudfront, you will see an 'Error Pages' tab. I had to add two 'Custom Error Responses' that handled 400 and 403. The details are the same for 400 and 403, so I only include a photo for 400. See below:

Basically, what is happening is you are telling Cloudfront that regardless of a 400 or 403 error, to redirect back to index.html, thus giving control to Angular to decide if it can go to the path or not. If you would like to serve the client a 400 or 403 error, you need to define these routes in Angular.

After setting up the two custom error responses, I deployed my cloudfront solutions and wallah, it worked!

I used the following article to help guide me to this solution.