Security by architecture, not by policy.

All inbound traffic is evaluated by an edge middleware layer before any request is admitted to the application runtime. Requests presenting absent or empty User-Agent headers are rejected outright. An explicit deny-list of 20+ adversarial signatures — encompassing vulnerability scanners (Nikto, sqlmap, Nuclei, Masscan), scraping frameworks (Scrapy, aiohttp, python-requests), and hostile crawlers (ByteSpider, PetalBot, HeadlessChrome) — is enforced per request. Per-IP rate limiting is applied across segmented route buckets via Upstash Redis, with a deterministic in-memory fallback to maintain protection across cold-start cycles.

Authorised indexing agents — Google, Bing, ClaudeBot, GPTBot, Perplexity, Applebot, Amazonbot, Mistral, and DeepSeek — are explicitly permitted to index public content for search and AI-answer visibility. All authenticated and API-layer routes (/api/, /auth/, /chat/) are disallowed in the robots directive. Static build artefacts (/_next/static/) are excluded from crawl scope to prevent crawl-budget exhaustion across versioned bundle files — a configuration that eliminated 46,000+ spurious crawl events previously consuming Googlebot's allocation.

All data in transit between clients and LumiChats infrastructure is protected under TLS. HTTP Strict Transport Security (HSTS) is enforced at the response header level, instructing conforming clients to refuse any plaintext connection attempt for the duration of the max-age window. No plaintext HTTP path to production infrastructure exists.

Following a comprehensive database access audit conducted at v2.0.0, all tables — including those with RLS enabled but lacking defined access policies — have been brought under explicit, restrictive RLS policies. Each policy enforces a strict subject-equals-resource constraint: authenticated principals may only read and write records where the owning user identifier matches their verified session identity. Cross-account data access at the database layer is not permitted by the enforced access control architecture.

AI model output undergoes mandatory sanitisation through DOMPurify prior to any DOM insertion, governed by a narrowly scoped allowlist of permitted tags and attributes. Dynamic string interpolation into innerHTML has been eliminated from all renderer paths; language identifiers in code blocks are written exclusively via the textContent API. All five KaTeX rendering instances have had the permissive trust:true flag replaced with a protocol-restricted trust callback, closing URL-injection vectors in mathematical output. These measures collectively and substantially reduce the primary cross-site scripting attack surface in the client renderer.

A Content Security Policy is enforced globally via response headers, restricting script execution to first-party origins and a single verified CDN (cdn.jsdelivr.net), stylesheet loading to first-party and Google Fonts, and network connectivity to Supabase and OpenRouter endpoints exclusively. Authentication routes (/auth/*) operate under a separately scoped policy that accommodates the OAuth redirect chain without relaxing restrictions on application routes. An explicit form-action directive restricts form submission targets to whitelisted authentication endpoints, preventing CSP bypass through form-based exfiltration.

OAuth 2.0 authentication flows implement the Proof Key for Code Exchange (PKCE) extension via Supabase SSR. The authorisation callback handler invokes exchangeCodeForSession() explicitly before processing session state events, ensuring the authorisation code is consumed and bound to the initiating session prior to any token issuance. This eliminates the open-redirect failure mode in which authorisation codes landed on unintended endpoints due to misconfigured redirect URI allowlists — a vulnerability present prior to v2.1.0.

All scripts loaded from third-party CDN origins carry cryptographic Subresource Integrity (SRI) attributes containing sha256 digests. Browser enforcement of SRI causes any load attempt to fail if the fetched resource does not produce the declared hash, providing a deterministic defence against supply-chain compromise scenarios in which a CDN origin serves modified or injected JavaScript.

All hyperlinks present in AI-generated HTML output are post-processed by a hardening function prior to rendering. Anchors bearing javascript: or data: scheme href values are stripped unconditionally. All remaining anchor elements opening in a new browsing context receive the rel=noopener noreferrer attribute, severing the opener relationship that would otherwise permit a destination document to redirect the originating tab — a class of attack known as reverse tabnapping.

All payment transactions are processed exclusively through Razorpay, a PCI-DSS Level 1 certified payment gateway. Cardholder data — including primary account numbers, CVV codes, and banking credentials — is transmitted directly from the client browser to Razorpay's certified infrastructure and is never received, stored, logged, or processed by LumiChats systems. LumiChats retains only transaction identifiers and plan entitlement metadata.

LumiChats does not sell, license, transfer, or otherwise disclose personal data — including account identifiers, correspondence, uploaded documents, or usage records — to third parties for commercial, advertising, or analytical purposes. Data collection is limited to the minimum necessary for service operation: account credentials, anonymised aggregate usage telemetry, and Razorpay-managed payment records. No behavioural profiling or secondary data monetisation takes place.

User messages are routed to foundation model infrastructure via OpenRouter. LumiChats does not access, analyse, or retain conversation content for any purpose beyond serving the immediate request. However, upstream inference providers — including OpenRouter and the model hosts they route to — operate under their own data retention and logging policies as defined in their respective terms of service. This disclosure is made in the interest of complete transparency regarding the boundaries of LumiChats' direct data control.

LumiChats respects data subject rights in alignment with the principles of the General Data Protection Regulation and materially equivalent regional frameworks. Users may submit requests for data access, rectification, erasure, or portability at any time by contacting lumichats@gmail.com. Requests are acknowledged promptly and processed in a timely and good-faith manner.

Security controls at LumiChats are not the output of a point-in-time audit — they are versioned, publicly documented, and incrementally shipped alongside product changes. Representative milestones: v2.0.0 introduced a full renderer XSS audit, mandatory CSP, database-wide RLS enforcement, and CDN SRI; v2.1.0 corrected the PKCE callback implementation and tightened CSP route scoping; v2.7.0 expanded the adversarial crawler deny-list; v3.5.0 hardened session verification. Every shield-tagged entry in the public changelog represents a discrete, production-deployed security control.