Skip to main content



  1. In AWS, set up a static site hosted in an S3 bucket.
  2. Set the permissions on the S3 bucket to include a public access policy and Cloudfront Object Access Identity.
  3. Set up Cloudfront to serve the content in the S3 bucket.


  1. Goto Lambda and make sure you’re in US-East-1
  2. Create a new function, make it Node.js.6.10
  3. Dump in your CSP.js, configured to do what you want. Note: start small and build your policy gradually.
  4. Save your code.
  5. Publish your code and make a note of the ARN (including version number).
  6. Select Cloudfront as a trigger, select Origin-Response, select the distribution that you’re going to use, hit the checkbox to say that you are ok with this, hit add and then go back to the top and hit save.
  7. Wait for the distribution to redeploy.
  8. Consider invalidating your origin objects if you’re impatient!
  9. Goto Mozilla Observatory Mozilla Observatory and test your policy.


Popular posts from this blog

Threat modelling this website

My previous post looked at producing a C4 model for my (simple) website. This post takes that a step further and looks at how we can use C4 modelling to elicit security and privacy threats using two frameworks: STRIDE . Most people know STRIDE, it’s derived from the Microsoft security threat modelling process from the early 2000s and represents Spoofing, Tampering, Repudiation, Information leakage, Denial of service and Elevation of privilege. LINDDUN . This is not so widely known but I first came across it in one of the Application Security Podcasts on  Privacy Threat Modelling . “ LINDDUN  was created in 2010 as a collaboration between the DistriNet and COSIC research groups of KU Leuven, Belgium”. It is a framework, not unlike STRIDE, which represents Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness and Non-compliance. However, both STRIDE and LINDDUN base themselves around classical threat modelling techniques which, in my opinion

Smart home equipment

My home is relatively smart in that I run a Home Assistant server with quite a few integrations with lighting, motion sensors, door/window sensors, CCTV, temp/humidity, energy and heating so I figured I'd list out my tech choices and any good/bad points that I've found while in use. My tech choices are now pretty stable after a few iterations over a few different types which means I have time to write a blog about it rather than play with Home Assistant all the time! Home Assistant This is the brains of the operation - it sits in the garage running on an old Shuttle PC with a DeConz Conbee II Zigbee stick in the back and is exposed to the internet so that the associated Android phone app can communicate with it at all times. That's pretty useful as I have a bunch of geo based automations hooked in but means that I have to be on top of my security model. Home Assistant has been rock solid for many years now. It's consumed A LOT of time in configuration and maintenance b

C4 modelling this website

This site has been around for a few years now and has changed significantly, mainly from an infrastructure perspective, over that time. That can be done as the site gets very few hits so I can use it to test features and experiment without worrying about outages.‌ In a work context, I very much promote the use of  C4 modelling  as a consistent and clear means of expressing a system architecture. C4 modelling struck a chord with me when I first came across it as it takes the best bits from UML and structured systems engineering, which is my background, but allows them to be used in a more agile (with a small ‘a’) software development context. Consistency is also the key; on a daily basis I review a handful of threat models which have historically been drawn using  any  drawing method (logical, physical, software based, high level, low level, etc) and tooling that you can imagine. Such a lack of consistency brings with it a time burden; it takes time to understand how each of the varying