Excellent question. And, although less important, the same header should be used across other TLS websites in Monzo’s portfolio, since a phishing attack might target trust in the blog or community site, and then provide a link to a fake monzo.me site.
Warning: you may get push back from some community members about reporting anything that is a security vulnerability as a bug, although there is no other more appropriate topic. But this missing header would appear as an issue in any application security vulnerability assessment Thank you for raising this.
For the record, I can’t remember seeing that happen in this community so I certainly wouldn’t worry about posting these sorts of questions.
The only thing I would say it’s probably better to have this type of discussion in the developer’s Slack channel. As it’s easier to have a quick back & forth conversation with the members of the team who deal with this sort of thing there + the average non-techy user will probably have no idea what you’re on about here
Though I don’t recall exactly what he said, he was already aware and basically I think it came down to a time/benefit balance. It doesn’t add a huge amount security-wise, although it is beneficial. It will likely be added at some point, along with HPKP.
I’m sure he’ll make a quick note if there is anything to add.
… should the Content Security Policy HTTP response header also not be defined on all TLS websites in Monzo’s portfolio? It can help reduce cross-site scripting risk, and missing security controls like this would be reported as a vulnerability in application security testing.
Github pages doesn’t implement HTTPS for custom domains at all.
Monzo are using a cloudflare proxy between the github pages site, and the users, which provides the HTTPS. So they should be perfectly able to add HSTS.