Security, built in.

How this website is built

The site is deliberately simple, because simple is easier to secure.

• Static and edge-served. Pages are plain HTML and CSS, served from Cloudflare's global network. There is no database or CMS behind the public site to attack.
• HTTPS everywhere. All traffic is encrypted with modern TLS (including TLS 1.3), with HTTP Strict Transport Security (HSTS) so browsers never fall back to plain HTTP.
• Post-quantum ready. Connections from supported browsers use hybrid post-quantum key agreement (combining X25519 with ML-KEM), protecting traffic against future “harvest now, decrypt later” attacks.
• Protected at the edge. Cloudflare's web application firewall (WAF) and always-on DDoS protection filter malicious traffic before it reaches the site, and its global CDN keeps it fast and available.
• A strict Content Security Policy. Pages can only load code from this site, plus Cloudflare’s cookieless Web Analytics beacon. The only other exception is Cloudflare Turnstile, on the contact page.
• No advertising or cross-site tracking. No advertising or social-media scripts, and our fonts are self-hosted. Visit statistics come from Cloudflare Web Analytics, which uses no cookies and doesn’t follow you around the web.
• Hardened headers. Including X-Content-Type-Options, Referrer-Policy, Permissions-Policy and frame protection.
• Bot protection without puzzles. The contact form uses Cloudflare Turnstile, which checks for bots without image CAPTCHAs.

How we look after information

We collect as little as possible, and only what we need to reply to you or to do the work.

• Data is encrypted in transit, and access is limited to the people who need it.
• Accounts are protected with strong, unique passwords and multi-factor authentication.
• Client credentials and secrets are kept in a password manager or secrets store, never in code or email.
• We remove access we no longer need at the end of a project.

For details of what personal data we hold and why, see the privacy notice.

How we work on client projects

Security is part of the job, not an extra. On projects we aim to:

• Use least-privilege access, and ask for only the permissions a task needs.
• Keep software and dependencies up to date, and choose well-maintained tools.
• Back up what matters, and check the backups can actually be restored.
• Document what we build, including how it is secured, so you are never dependent on us.

Vulnerability disclosure policy

If you think you've found a security issue in anything MOSH runs, please tell us. We welcome reports from anyone, and we'll work with you to understand and fix the issue.

How to report

Email security@mosh.co.uk with:

• A description of the issue and where it is (URL, component or service).
• Steps to reproduce it, and a proof of concept if you have one.
• The impact you think it has, and how you'd like to be credited (if at all).

What to expect

• We'll acknowledge your report, normally within five working days.
• We'll keep you updated as we investigate, and tell you when it's fixed.
• With your permission, we'll credit you once the issue is resolved.

Scope

In scope: mosh.co.uk and its subdomains. Out of scope: denial-of-service testing, social engineering, physical attacks, spam, reports from automated scanners without a demonstrated impact, and issues in third-party services we use (please report those to the provider).

Safe harbour

If you act in good faith, follow this policy, avoid privacy violations and service disruption, and give us reasonable time to fix an issue before disclosing it, we will not take legal action against you. We don't currently run a paid bug bounty.

Our security.txt file follows RFC 9116.