Security Statement

Transport security

The site is served over HTTPS. Responses carry a Strict-Transport-Security header with a two-year max-age and includeSubDomains, so a browser that has seen the site once will refuse to connect over plain HTTP afterwards. The Content Security Policy also sets upgrade-insecure-requests.

We have deliberately not added the preload directive. Preloading is difficult to reverse and should only be enabled once every subdomain of the domain is confirmed HTTPS-only.

Response headers

Every response includes:

• Content-Security-Policy restricting where scripts, styles, images, fonts and connections may come from
• X-Content-Type-Options: nosniff, preventing MIME type guessing
• X-Frame-Options: DENY and a CSP frame-ancestors 'none' directive, so the site cannot be framed for clickjacking
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy switching off camera, microphone, geolocation, payment, USB, sensors and interest-based advertising APIs
• Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy set to same-origin

The X-Powered-By header is disabled and production browser source maps are not published, so the build does not advertise its framework version or expose original source.

Content Security Policy, and its known limitation

The policy sets default-src 'self' and pins object-src, base-uri and frame-ancestors to 'none'. No third-party script origin is permitted except Cloudflare Turnstile, which is used for bot protection on our forms. Fonts are self-hosted, so no external font origin is allowed. Images are restricted to this origin and inline data URIs.

The honest limitation: the policy permits 'unsafe-inline' for scripts and styles. A nonce-based policy would be stronger, but our framework can only apply a per-request nonce to pages rendered on every request, and every page here is generated once at build time so that it loads quickly. We chose static generation and compensated elsewhere: no visitor-supplied content is ever rendered as HTML on this site, the only place we inject raw markup is structured data that we generate and escape ourselves, and articles are compiled from source at build time rather than authored through a CMS. If that ever changes, the policy changes with it.

Form submissions

The enquiry, discovery workshop and careers forms all go through the same server-side pipeline. Nothing is processed in your browser and no mail credentials exist in any code sent to it.

• Strict validation. Every field is checked server-side against a schema with a maximum length. Unknown fields are rejected outright rather than ignored, so an extra input added to the page is not accepted.
• Header injection defence. Any value that could reach an email header is rejected if it contains a carriage return, a line feed, a Unicode line separator, a control character, or a percent-encoded line break, including double and triple encoding.
• Fixed sender, restricted reply. Notification mail is always sent from one verified address that we control. Your address is used only as the Reply-To, and only after it is confirmed to be a single well-formed address with no embedded separators or display name.
• Fixed recipients. Where a submission is routed is decided by the server from a fixed list. No value you send can add, change or redirect a recipient.
• Output encoding. Everything you type is escaped before it appears in the notification email, and a plain-text version is sent alongside the HTML one.
• Rate limiting. Submissions are capped per connection over a rolling window. The key is a keyed hash, so no raw IP address is held.
• Bot protection. A hidden decoy field, a server-signed timing check that rejects implausibly fast submissions and cannot be backdated by the client, and optional Cloudflare Turnstile verification performed server-side.
• Cross-origin protection. Form submissions are rejected unless they originate from this site.
• No file uploads. No form on this site accepts an attachment, which removes malware upload as a category of risk entirely.
• Generic errors. If something fails we show a generic message. We never return a provider error, a stack trace or a diagnostic detail to the browser.

What happens to your enquiry

Form submissions are delivered by email to Celestique Cloud inboxes and are not stored in a database on this website. Delivery is handled by a third-party transactional email provider. What we collect and why is set out in our privacy policy, which is currently a draft pending legal review.

Logging

We log that a submission happened, which form it was, its category and whether it succeeded. We do not log names, email addresses, message content or raw IP addresses. Log values are encoded so that a line break inside submitted text cannot forge a false log entry.

Third-party assets

Microsoft and AWS product icons shown on our service pages are served from this site, not linked from vendor servers, so viewing a page does not disclose your visit to a third party. Every icon file is checked at build time and the build fails if any file contains a script, an event handler, an embedded external reference or an XML entity declaration. Each file’s hash is recorded, so the build also fails if a file has been altered since it was verified.

Fonts are self-hosted. There are no third-party analytics, advertising or social media tracking scripts on this site.

Dependencies

The site is built on a current supported release of its framework, with a deliberately small dependency list. Dependencies are pinned in a lockfile so that a build is reproducible, and are reviewed and updated as part of ongoing maintenance.

Reporting a vulnerability

If you believe you have found a security issue in this website, please tell us at director@celestiquecloud.com with Security in the subject line. Include enough detail for us to reproduce it, and a way to contact you.

What we commit to:

• we will acknowledge your report and investigate it;
• we will tell you what we found and what we intend to do;
• we will not pursue action against anyone who reports an issue in good faith, tests only against their own submissions, and does not access, alter or destroy other people’s data.

We are not able to commit to a response time, and we do not operate a paid bug bounty. Please do not run denial-of-service testing, automated vulnerability scanners at volume, or social engineering against our people.