One of the things I had missed when redesigning this site is how non HTTPS connections were to be handled. I did check that https links were created internally, and I thought I was effectively testing that http got redirected to https but it turns out my test wasn't great. This was because I'm using the HTTPS everywhere plugin (you should too), so I didn't realize that HTTP requests were not being forced to HTTPS on the server because my browser was already doing it.

Part of the reason why you should care is that there's a class of attacks known as downgrade attacks, which open you up to man-in-the-middle attacks. For example say you go to https://www.example.com you are getting some assurances from the public key infrastructure amd the cryptography that you are indeed connecting to the server you think you are connecting to without anything in the middle changing the data. If someone can downgrade the traffic to https://www.example.com then they are able to insert their own page in the middle far more easily on the unencrypted connection page, by forcing the site to only connect via HTTPS this specific issue is mitigated fairly well.

Since I've been hosting this site on Python Anywhere I had a moment of discomfort because I didn't know how much work it would take to change.

Good thing is that since I last had to change settings around Python Anywhere just gives a nice button for just this behavior in the web apps settings:

Which is now:

This means that now all requests will be via HTTPS. I took substantially more time writing this post than actually fixing the issue itself!