Security Policy

The Plain-Language Summary

xolro.com is a static, database-free website. There are no user accounts, no passwords, no sessions and no stored customer records — which removes most of the things that get breached in the first place. The single exception is our contact form, and this page describes exactly how that one path is protected.

1. Purpose

This Security Policy defines the technical and organizational safeguards Xolro implements to ensure:

Confidentiality of the enquiries and contact details entrusted to us
Integrity of the information published on this website
Availability and reliability of the site and its contact channel

2. Scope

This policy applies to the xolro.com website, its single contact API endpoint, the hosting and email infrastructure behind them, and all personal data processed through them.

Xolro's products — including Spendra, My Daily Buddy, Xolro Launcher and Xolro Quotation — are currently in development and are not yet distributed to users. They are not in scope here. Each will carry its own security documentation when it ships, because each has an architecture this policy does not describe.

3. Infrastructure Security

3.1 Hosting Environment

Hosted on a managed cloud platform with a global edge network; Indian traffic is served from the Mumbai region
Production deploys are gated to the main branch only; all other branches are ignored at build time
Separate production and preview environments, with environment variables scoped per environment
Administrative access to the hosting account is restricted to authorized Xolro personnel and protected with two-factor authentication

3.2 Platform Hardening

We operate no virtual private servers and no self-managed operating systems. There is no SSH surface, no root shell, no long-lived host and no open port for us to misconfigure. OS patching, kernel updates and network-level hardening are the platform provider's responsibility, performed continuously across their fleet.

Nearly every route on this site is prerendered to static HTML at build time and served from cache. Only the contact endpoint executes code in response to a request, and it does so in a short-lived, isolated serverless function with no persistent filesystem.

3.3 Network Security

HTTPS enforced site-wide over TLS 1.2 or higher
HTTP Strict Transport Security (HSTS) with a two-year max-age, so browsers refuse to connect over plain HTTP
Platform-level DDoS mitigation and edge caching absorb volumetric traffic before it reaches any application code
TLS certificates provisioned and renewed automatically

4. Application Security

4.1 Secure Development Lifecycle

Built on Next.js and React with TypeScript in strict mode; the build fails on type errors rather than shipping them
All source is version-controlled, with changes reviewed before they reach the production branch
Secrets are supplied exclusively through environment variables. Environment files are excluded from version control and no credential is ever committed to the repository

4.2 Authentication

This website has no authentication surface. There are no user accounts, no login, no passwords, no sessions and no tokens. Nothing on this site requires you to identify yourself, so there are no credentials of yours for an attacker to steal from us.

Where Xolro personnel hold administrative credentials for our hosting and email providers, those accounts are protected with two-factor authentication and are not shared between individuals.

4.3 Authorization

Because the site serves only public content and exposes no privileged operation, there is no role hierarchy or permission model to enforce at runtime. Authorization applies only to internal access, described in Section 7.

4.4 API Security

The site exposes exactly one endpoint that accepts input — the contact form handler. It applies the following controls:

Input validation. Required fields are enforced and the email address is format-checked before anything is processed; invalid submissions are rejected
Output escaping. Every submitted value is HTML-escaped before being placed into the notification email, so a submission cannot inject markup or script into what we read
Mail header injection protection. Carriage returns and line feeds are collapsed out of submitted values, preventing a submission from forging additional email headers or extra recipients
No SQL surface. There is no database behind this site, so SQL injection is not applicable
No session surface. The site sets no authentication cookies and maintains no session state, so there is no session for a cross-site request to forge

5. Data Security

5.1 Data Classification

Sensitive: the contents of an enquiry — your name, email address, company and message, which may describe a confidential business problem
Operational: server access logs and aggregated page-view counts
Non-sensitive: everything published on the site itself

We do not collect financial, biometric, health or government identification data through this website, and we hold no student or employee records.

5.2 Data Storage

There is no application database. An enquiry is never written to website storage — it is relayed as an email and comes to rest in the Xolro support mailbox, where it is governed by the retention practice in our DPDP Compliance notice.

5.3 Encryption

In transit from your browser to us: HTTPS/TLS 1.2+, enforced by HSTS
In transit from us to our mail provider: authenticated SMTP over an implicit TLS connection
At rest: mailbox contents are encrypted at rest by our email provider
Provider credentials are held as encrypted environment variables and are never exposed to the browser. The mail credential is a scoped application-specific password, not an account password, so it can be revoked without disturbing the account

5.4 Backup and Recovery

The website is reproducible from version control: its entire content and configuration live in a Git repository, and every production deploy is a retained, individually addressable immutable build that can be rolled back. Enquiry correspondence is backed up as part of our email provider's managed service.

6. Attack Surface Minimisation

We treat a small attack surface as the primary control rather than a happy accident. The following are absent from this website by design, and each absence removes an entire class of vulnerability:

No user accounts, credentials or password storage
No database, and therefore no injection or dump exposure
No file upload path
No payment processing and no cardholder data
No third-party advertising, marketing or tracking scripts
No admin panel or content management back end

As Xolro's products move from development into release, features will be added only alongside the controls they require — not ahead of them.

7. Access Control and Audit

7.1 Internal Access Control

Access to the hosting account, the code repository and the support mailbox is limited to authorized Xolro personnel
Access is granted on a least-privilege basis and revoked when it is no longer needed
Administrative accounts are individual, never shared

7.2 Audit Trail

Every change to this website is recorded in version control with its author and timestamp, and every deployment is logged by the hosting platform. Because the site holds no user-generated records, there is no record-level audit log to maintain — the deployment history is the audit trail.

8. Monitoring and Logging

Platform-level request and function logs capture errors and runtime exceptions
Failed contact deliveries are logged explicitly so that a message is never reported as sent when it was not
Aggregated, cookieless traffic analytics surface anomalies in request volume
Access to these logs is restricted to authorized personnel

9. Incident Response

In the event of a security incident, Xolro follows this sequence:

Detection and validation of the report or alert
Immediate containment — which for this site can include rolling back to a known-good deployment within minutes, and revoking affected credentials
Root cause analysis
Remediation and verification of the fix
Notification of affected individuals where required
Post-incident review, and a change to prevent recurrence

10. Vulnerability Management

Dependencies — Node.js, Next.js, React and supporting libraries — are reviewed and updated on a regular cadence
Security patches for known advisories affecting our dependency tree are applied promptly rather than deferred to a release cycle
The production build is regenerated on every change, so a patched dependency reaches production as soon as it is merged

11. Third-Party Security

We keep the vendor list deliberately short. This website depends on exactly two categories of third party:

A managed cloud hosting and CDN provider — serves the site, terminates TLS and runs the contact function
A business email provider — delivers and stores enquiries

Controls applied: minimal data shared with each; all integrations over TLS 1.2+; credentials stored as encrypted environment variables and never exposed to the browser or committed to source control; provider administrative accounts protected with two-factor authentication.

This website integrates no payment gateway, no SMS or messaging provider and no advertising network.

12. Data Breach Policy

On confirmation of a personal data breach we will contain and investigate it immediately, assess its impact and scope, notify each affected individual and the Data Protection Board of India as required under the Digital Personal Data Protection Act, 2023, and implement corrective measures. Our notification will state what happened, what data was involved and what you can do about it. The procedure is set out in full in our DPDP Compliance notice.

13. Compliance

Our practices are aligned with:

The Information Technology Act, 2000 (India)
The SPDI Rules, 2011 — reasonable security practices and procedures
The Digital Personal Data Protection Act, 2023 — see our DPDP Compliance notice
Industry-standard practices for static web delivery

We hold no security certification at this time. We do not claim ISO 27001 or SOC 2 compliance, and we will say so here plainly until such time as an accredited audit has actually been completed.

14. Business Continuity and Disaster Recovery

A static site backed by version control recovers quickly by construction. Our targets for this website are:

RPO (Recovery Point Objective): effectively zero for site content — the Git repository is the source of truth and no site state exists outside it
RTO (Recovery Time Objective): under one hour — a corrupted or compromised deployment is restored by rolling back to a previous immutable build, or by rebuilding from the repository

Should the contact endpoint be unavailable, the form falls back to opening a draft in your own email client, so the channel degrades rather than failing silently.

15. User Responsibilities

This site asks very little of you, because it gives you no account to protect. We ask only that you:

Do not send passwords, API keys, financial details or other secrets through the contact form — it is an email channel, not a secure vault
Verify that you are on https://xolro.com before submitting anything
Report anything suspicious to us using the contact below

16. Limitations

Security controls reduce risk; they do not eliminate it. No organisation can honestly promise otherwise. The measures described here do not fully protect against zero-day vulnerabilities in upstream software, compromise of a third-party provider, advanced persistent threats, or interception occurring on a visitor's own device or network.

We describe here what we actually do — not what we aspire to. Where a control is absent, this page says so.

17. Policy Updates

This policy will be updated as our architecture changes — in particular as Xolro's products move from development into release and introduce accounts, storage and integrations that this website does not have. The effective date at the top of this page reflects the current version.

18. Contact and Vulnerability Reporting

To report a security concern or a suspected vulnerability, email support@xolro.com with the subject line "Security Report". Please include enough detail to reproduce the issue.

We welcome good-faith reports and will not pursue action against researchers who investigate responsibly, avoid privacy violations and service degradation, and give us reasonable time to remediate before public disclosure. We aim to acknowledge reports within 3 working days.

See also our DPDP Compliance notice, Privacy Policy and Terms of Use.