I started off with the simplest option I could think of - a static site hosted directly from Amazon S3. I’d been meaning to sign up for AWS and play around with the free tier of services. Followed the tutorial.

I went with Gitlab for my version control since I’m familiar with it from work, and I really like their Pipeline/CI/CD setup.

Since the website is simply a series of files and folders in an S3 bucket, all I need to do in the pipeline to update it is copy my source files from Gitlab to S3, using a docker image with aws-cli installed:

aws s3 cp src s3://$S3_BUCKET_NAME/ --recursive

So, at the beginning, my source files are exactly what goes on my website. It’s very crude. There’s no templating, no SCSS or Typescript, no bundling or minifying. Those conveniences will come later.

Security is pretty important to me. Obviously my simple static website isn’t as much of a risk as a full featured web app.

But simplicity also means it’s easy to follow strong security habits from the get-go.

So for starters: HTTPS. Thanks to Let’s Encrypt and AWS Certificate Manager, it’s never been easier to get SSL/TLS certificates. I went with AWS since it gels nicely with the other AWS infrastructure and it’s tricky to get the Let’s Encrypt certificate automatically renewed without an actual web server.

To use HTTPS with an S3-hosted static website, you need to run CloudFront. This means I have to worry about flushing the cache when I make updates, but does give me a bit more control over the site like setting custom request headers (more on that later).

I immediately restricted it to TLSv1.2 - everything past IE 10 can use it now, and it’s not like I have any legacy customers to support.

Once I had HTTPS working, I felt ready to add the Strict-Transport-Security headers to lock in HTTPS. I even went ahead and added my domain to the HSTS Preload List so all browsers will only access it over HTTPS. I’m committed now.

Next on the checklist was other security headers:

The Content-Security-Policy header should be interesting as a restriction to work around - no inline Javascript or CSS (I hate those anyway, so that isn’t hard), and no externally hosted JS (so no bringing in jQuery from a CDN for instance).

It’s a tight restriction to work within, but very manageable for a simple website, and I think it’s a good constraint to have.

I used Mozilla Observatory, SSL Labs and securityheaders.io to verify these security changes.