Security and data
How we secure this site and handle your data.
This page explains how Aelsha Innovations secures its website, handles enquiry data and treats client data in engagements, and how to report a vulnerability. Every claim about the website is tested against the built site before each release. Our commitments on client data are set out below and confirmed in each signed engagement agreement.
Built and checked on
What this website does, and does not do
The site is a set of static pages. Until you accept analytics cookies it sets no cookies and loads nothing from anyone else. The only code of ours that runs on a server is the service behind the contact form and the newsletter sign-up.
Static pages, and one form service
Every page is built to plain HTML before release and served as a file. The only server-side code is the service that receives the contact form and newsletter sign-ups, and the only data it stores is the enquiries and sign-ups people send.
No cookies before you consent
Nothing sets a cookie unless you accept analytics in the cookie choice, and no response ever sends one. Your theme and cookie choices stay in your own browser storage and are never sent anywhere.
Nothing from other domains before you consent
No tags, fonts, embeds or scripts from other domains. Google Analytics loads only after you accept, from hosts the policy below names exactly; everything else is blocked.
Every script is hashed
Each script file name carries a hash of its contents. The build fails if a page contains an inline script that can run, or an unhashed one. The only inline script element is structured data (JSON-LD), which browsers do not run.
No framework JavaScript
Pages ship no client framework. The few small scripts only enhance things already on the page, such as the theme control and the menu. If you accept analytics, Google’s analytics script also loads.
What the contact form sends
When you press send, the form sends what you typed to our form service, on this site’s own address. The service stores the enquiry in a database in India, emails it to our business mailboxes and emails you a confirmation with a reference number. It never stores your IP address, only a keyed one-way hash of it, used to limit abuse. If you accept analytics, only the topic you chose and how you heard about us are counted. The newsletter sign-up sends only your email address, which we keep for up to 7 days until you confirm it from the email we send, and then until you unsubscribe.
Three layers, and one form service
A page request passes through the hosting edge, which adds the security headers, and lands on a plain file. Only a form submission, from the contact form or the newsletter, goes one step further, to our form service.
| Layer | What it does | How to check it |
|---|---|---|
| Your browser | Enforces the policy the edge sends: it refuses scripts, frames and requests the policy does not allow. | Open the developer console on any page; it reports a policy violation if one occurs. |
| Hosting edge (CDN) | Adds the security headers to every page and file and tells browsers to use HTTPS only. Old addresses that we moved redirect to the new address. | curl -sI https://aelsha.com/ (see the next section). |
| Static files | The pages, styles and hashed scripts, built before release and served unchanged. | View source: the only inline script is the JSON-LD structured-data block, which does not run, and script file names end in a content hash. |
| Form service | Receives only the contact form, at /api/leads on this site, and the newsletter sign-up, confirmation and unsubscribe, at /api/newsletter. It checks every field, refuses requests from other sites, limits how often anyone can send and how much mail any address receives, stores the enquiry or sign-up and sends the emails. | curl -s https://aelsha.com/api/health answers with its version; a form post from any other site is refused. |
Verify it yourself
Do not take our word for it. One command shows the response headers for the home page, and the same headers are set on every page.
curl -sI https://aelsha.com/Headers to look for
| Header | What you should see | What it prevents |
|---|---|---|
content-security-policy | default-src 'self'; script-src 'self' https://www.googletagmanager.com; … object-src 'none'; … frame-ancestors 'none'; require-trusted-types-for 'script'; … | Scripts from anywhere but this site and the analytics tag you can accept, plugins, other sites framing ours, and scripts writing raw HTML into the page. |
strict-transport-security | max-age=31536000; includeSubDomains | Downgrading a visit to unencrypted HTTP. |
x-content-type-options | nosniff | The browser guessing a file type and running it as a script. |
cross-origin-opener-policy | same-origin | Other windows reaching into this page. |
cross-origin-resource-policy | same-origin | Other sites loading our files as their own resources. |
x-frame-options | DENY | Clickjacking in older browsers (frame-ancestors covers newer ones). |
referrer-policy | strict-origin-when-cross-origin | Leaking full page addresses to other sites. |
permissions-policy | camera=(), microphone=(), geolocation=(), payment=(), usb=(), browsing-topics=() | Pages asking for the camera, microphone, location, payments or USB devices, or using the browser’s Topics interest API. |
Also look for what is missing: there is no set-cookie header.
No exceptions: the policy allows no inline executable scripts and no inline styles, and nothing in it says 'unsafe-inline' or 'unsafe-eval'.
curl -s https://aelsha.com/.well-known/security.txtEnquiry data and client data
The site keeps only the enquiries you send with the contact form and the email address you give the newsletter sign-up. Nothing else you type leaves your browser.
Enquiries and sign-ups
When you send the contact form, we store what you entered (your name, email address, phone number if you gave one, company, topic, how you heard about us and your message), with the date, your browser’s user-agent string and a keyed one-way hash of your IP address, never the address itself. The enquiry is stored in a database in India and emailed to our business mailboxes, and you get an automatic confirmation by email with a reference number. How long we keep it is in the privacy notice. If you email us directly instead, your email is handled like any email to support@aelsha.com. A newsletter sign-up stores your email address, whether you confirmed it, its dates and the version of the privacy notice you saw; unsubscribing deletes it.
Hosting
Pages are delivered by our hosting provider’s global network, under its terms. Our form service’s own logs record each request’s path, status and timing, with email addresses masked, and never your message, your phone number or your IP address. Like any hosting provider, our cloud provider keeps standard request logs of its own.
Client data in engagements
We handle client data only as the signed agreement for the engagement sets out, and we keep it confidential under that agreement. We ask only for the access the agreed work needs, and agree it with you in writing before work starts. Where we can, we work inside your own environment and accounts, remotely by default, rather than copying data out of them. Where the work calls an AI model, it uses the provider and keys you choose and agree in writing. When the engagement ends, we return or delete your data as the agreement sets out. Retention periods and any service providers involved are set in the agreement, and we answer questions about them in your vendor review.
Checks before each release
Before each release we run the checks below. They are defined in the site repository and run from one command, so the list here is the list that exists.
- Dependency versions are checked against the latest stable releases.
- Type checking, linting and formatting.
- Unit tests for the build scripts and shared logic.
- A build gate: no inline executable scripts, every script content-hashed, no framework runtime, size budgets, a banned-content check, and a policy computed from the built pages.
- Browser tests in Chromium, Firefox, WebKit and a phone-sized viewport, against the built site: pages load without console errors or requests to other domains, and the security headers are present on every route.
- An audit of dependencies for known high-severity vulnerabilities.
- A scan for committed secrets.
- Static analysis of the source with Semgrep.
- A lint of the container build file.
Report a vulnerability
Email security@aelsha.com directly with what you found, how to reproduce it and its impact.
Include the page or address affected and the steps you took. Do not include real credentials or other people’s data. The same contact is published in our security.txt file.
Questions for your vendor review
Tell us what your review needs. We answer by email and say plainly when the answer is not yet.