in Malaysia, Security & Privacy

Security Headers for Gov-TLS-Audit

Gov-TLS-Audit got a brand new domain today. No longer is it sharing a crummy domain with sayakenahack (which is still blocked in Malaysia!), it now has a place to call it’s own.

The domain cost me a whooping $18.00/yr on AWS, and involved a couple hours of registration and migration.

So I felt that while migrating domains, I might as well implement proper security headers as well. Security Headers are HTTP Headers that instruct the browser to deny or allow certain things, the idea being the more information the site tells the browser about itself, the less susceptible it is to attack.

I was shocked to find out that Gov-TLS-Audit had no security headers at all! I assumed AWS (specifically CloudFront) would take care of ‘some’ http headers for me — I was mistaken. Cloudfront takes care of the TLS implementation, but does not implement any security header for you, not even strict-transport-security which is TLS related.

So unsurprisingly, a newly created cloudfront distribution, using the reference AWS implementation, fails miserably when it comes to security headers.

I guess the reason is that HTTP headers are very site-dependant. Had Cloudfront done it automatically, it might have broken a majority of sites And implementing headers is one thing, fixing the underlying problem is another.

But what security headers to implement?

HTTP Security Headers

Mozilla have a great page on web security, with a cheatsheet of things to do in a proposed order. The cheatsheet and my score for (before I changed it) are here:

The list is arranged in priority order, with the highest priority actions at the top, so there was a lot of red for me, fortunately all of them was http headers, so it was a simple fix (sort of). In fact, I could fix all but one of the problems above by just setting the following headers:

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=63072000
Referrer-Policy: no-referrer

The most difficult http header to tackle was the Content Security Policy. So before we go into adding http headers on Cloudfront, let’s first understand what content-security-policy is.

Content Security Policy

There’s a great many resources on Content Security Policies (CSP) from Mozilla, & troyhunt. It all boils down to this, a CSP is a directive to the browser on what resources can be loaded on your website. It tells the browser, what scripts, images, fonts, etc can be loaded and which sources are permitted for these elements to be loaded from.

This prevents anyone from inserting images, scripts and even fonts directly on the page, because the CSP would not allow it. You can even set two CSPs on your site, one that will be enforced by the browser (will not load scripts, unless whitelisted by CSP) and one that will merely be reported by the browser — a report will be sent to the endpoint for further screening.

At the end though, this was the CSP I settled on:

Content-Security-Policy: default-src ‘none’; script-src ‘self’; style-src ‘self’; upgrade-insecure-requests; form-action ‘self’; connect-src ‘self’; img-src ‘self’; frame-ancestors ‘none’; base-uri ‘self’;

It might look confusing, it’s basically a bunch of semi-colon delimited fields, which we can read last-to-first.


This tells the browser to report all violations to the endpoint above. Report-Uri is a collaboration between troyhunt and scotthelme, and it’s a great tool to get started for securing your site.

base-uri ‘self’;

This limits any <base> elements to origin. The <base> elements specifies the base url for all relative urls to use. There isn’t a good reason for this to be anything other than origin.

frame-ancestors ‘none’;

This specifies valid parents that may embed on a page, since has no embeds like tweets, or youtube videos, I didn’t need this. So I set to ‘none’. Note that this element doesn’t fallback to default-src.

img-src ‘self’;

This tells the browser that all images should only be loaded from origin. i.e. all images on this site should only come from and nowhere else.

connect-src ‘self’

The API on the site actually connects to but just to future proof this, I decided to allow as well. Changing a CSP on CloudFront using the method we’re about to use is painfully slow (as we’ll see).

form-action ‘self’;

All forms should only post to origin.


Any requests from site should be upgraded to https instead of http. This will actually give you a performance boost if you have a lot of http requests, and obviously make those request more secure.

style-src ‘self’;

All css files should come either from origin or, since i use bootstrap’s bootstrap.min.css.

script-src ‘self’;

Scripts should only be trusted from origin, maxcdn and code.jquery. Important to note, that the html on the page sources these scripts via https, anonymously, and using an integrity sha-256 check to ensure they haven’t been manipulated.

default-src ‘none’;

Block everything by default unless explicitly mentioned here. Not all fields above will fallback to default, so you still have to hand-pick each field to be sure, but a default of ‘none’ is a good starting point.

Now how to add these headers to the page?

[email protected] to insert http headers

The only way (I know off) to insert http headers into a S3-based website on AWS, is via the use of CloudFront + [email protected] You need CloudFront anyway for custom domains with TLS, and now you need an additional [email protected] implementation to inject those http headers into the user response.

Amazon allow you to run [email protected] at 4 possible point in time, during a user request. The seemingly obvious place to inject them would be just before a response is sent to the user (viewer-response), but this is expensive as we’d need to run the Lambda functions at every user response.

The better place to run them is at origin-response, i.e. after CloudFront has retrieved the object from the origin, but BEFORE it has saved it to cache. This way your injected http-headers get pushed to cache, and your lambda function is no longer needed. It’s faster, and less expensive — although I’m still griping over the need to run a lambda function to do this.

In the end, this is the JavaScript function that injects the headers into my site:


Testing your CSP

However, origin-response is a pain to test, because any change to the CSP, requires that you redeploy the [email protected] functions (which aren’t to deploy as their non-edge siblings), then wait for it to propagate across all edges and invalidate the cache. That’s a lot of steps to test.

Instead, I found, running unit test with BurpSuite to be easier. I initially considered spinning up an Apache webserver just to do this, but that would also require cert generation etc. BurpSuite also requires cert generation, but the process is pretty straightforward as the tool generates them for you already.

I found that by simply running a proxy, you can add a CSP http header to the response, to check if your CSP works. You don’t even need to worry about looking at the browser console, as BurpSuite will intercept the outgoing post to your report-uri instantly, and you can see it on the same tool.

This allows you to quickly fine-tune your CSP, to get it out of ‘unit-test’ mode. This won’t work if you’ve got 100’s of pages to test with, but works pretty well for something like, which only has a handful of pages, typically running the same scripts.

Deploying [email protected]

Once you’re OK with the CSP, and pretty confident if won’t break. Create a [email protected] function (remember it has to be in us-east-1/N.Virginia), and associate it with the CloudFront behavior.

Now, here’s the tricky part, [email protected] requires a specific version of your function. Unlike regular lambda’s that can reference $Latest, [email protected] requires that you publish a version of the function, and use the published version.

Once you have a version of the function, you can then associate it with a CloudFront behavior — remember, the function is associated with the CloudFront Behavior, not CloudFront distribution. A behavior is a path specific parameter, that specifies which origin CloudFront should reference, e.g. I have a behavior for /api/v2 that sends traffic to an API Gateway, and a /files behavior that redirects traffic to an S3 bucket, and finally a * with takes all other traffic to a html file hosted on a separate S3 bucket.

For the purpose of this exercise, I only embed the security headers for the site (and not the API) — the API Gateway can use it’s own lambda functions to provide the headers.

This is the best link on implementing security headers via [email protected].

Modifying [email protected]

But once you’ve got your http headers deployed is the only time you can test them against Mozilla’s observatory, or scott helme’s and obviously you’ll probably want to make changes.

There is a serverless plugin available to deploy [email protected], but the plugin required to deploy the function on new CloudFront distributions, not existing ones. So there is a fairly manual way to do this.

By first deleting the trigger old lambda function — and then creating a new version of function, and repeating the previous steps. It’s not just tedious and manual (3 button clicks) — it’s very very slow. The CloudFront distribution takes ~20 minutes to propagate and then you still need to invalidate the cache, another ~5 minutes before you can test.

Hence, try to test as much as possible using BurpSuite, and use this as a last minute tidy up.


Once all was done, and a couple iterative re-test, here’s what I got.

And of course, a few more tweaks (like base-uri and frame-ancestors) got me this on Mozilla’s observatory — which had no recommended changes for me (whoop!)

Not bad for a weekend’s work.


As much work as putting a CSP together is, doing this early on in your project is far easier than doing it later. If you’re thinking of starting a project today, make sure you implement a CSP as part of your ‘hello world’ phase. Trying to undo CSP errors later on is a nightmare.

If you’ve already got a project, putting a CSP together for a blog with 500+ post, and God knows how many embeds is going to be painful, but you can always start with very restrictive CSPs in report-only mode, and go from there (which is the recommended).

Now that has a new domain, and spanking new domains, I’ll be looking to do some robots.txt, security.txt and contributions.json files before finally biting the bullet and try to make it 100% serverless.