Security

1. Account security

• Passwords are hashed with scrypt, a memory-hard algorithm designed to resist GPU cracking. Each password gets its own random 16-byte salt. Plain-text passwords are never written to disk or logs.
• Password comparison is timing-safe, so an attacker cannot learn a hash by measuring how long a failed login takes.
• Session tokens are 256 bits of cryptographic randomness, generated per login and invalidated on logout.
• Authentication uses bearer tokens rather than cookies, which removes the classic cross-site request forgery attack path.

2. Transport and headers

• All production traffic is served over HTTPS.
• HSTS is sent on HTTPS responses in production, so browsers refuse to downgrade to plain HTTP.
• X-Content-Type-Options: nosniff prevents browsers from reinterpreting a response as executable content.
• X-Frame-Options: SAMEORIGIN blocks clickjacking via hostile iframes.
• Referrer-Policy: strict-origin-when-cross-origin stops full URLs leaking to third parties.
• Permissions-Policy disables camera, microphone, geolocation, and payment APIs, none of which the app uses.

3. Rate limiting and abuse

• Login and signup are limited to 20 attempts per IP per 15 minutes, which makes credential brute-forcing impractical.
• Chat is limited to 40 messages per IP per minute to blunt scripted abuse of a public endpoint.
• Request bodies are size-capped, and chat messages are length-limited, so a single request cannot exhaust memory.
• Per-account monthly message quotas are enforced by plan.
• Rate-limited responses return 429 with a Retry-After header.

4. Secrets and configuration

• API keys, admin secrets, and provider credentials live in server-side environment variables and are never sent to the browser.
• The .env file is git-ignored so credentials do not reach source control.
• Billing webhooks are verified by HMAC signature before any account change is applied, so a forged webhook cannot upgrade a plan.
• Administrative endpoints require a separate admin secret in addition to normal authentication.

5. Data handling

• Every business is scoped to an owner account, and ownership is checked before a business can be read or overwritten.
• Owners can only see leads, appointments, and conversations belonging to businesses they own.
• Card details never touch our servers; payment is handled entirely by our payment provider.
• Data deletion and export requests are handled as described in our Privacy Policy.

6. AI processing

The assistant is instructed to answer only from the knowledge its owner has provided, and not to invent prices or policies. Two processing modes exist:

• Without a language model provider configured, replies are generated on our own servers from your trained knowledge. No conversation content leaves our infrastructure.
• With a provider configured, message content and your business knowledge are sent to that provider to generate a reply, under their terms. Sub-processors are listed in the Privacy Policy.

Your business knowledge and your visitors' conversations are not used to train models for other customers.

7. Widget isolation

The embeddable widget namespaces all of its styles and scripts so it cannot collide with, or be affected by, the CSS and JavaScript on your website. It requests no special browser permissions and does not read the surrounding page's content.

8. What we have not built yet

Stated plainly so you can make an informed decision:

• No SOC 2 or ISO 27001 certification. We have not undergone a third-party audit.
• No two-factor authentication on owner accounts yet.
• No Content-Security-Policy header yet — the current pages rely on inline styles and scripts, which a strict policy would break.
• Rate limits are per server instance, held in memory. Running multiple instances would need a shared store to enforce a single global limit.
• Application data is stored in JSON files on disk, not an encrypted database. Encryption at rest depends on your hosting provider's disk encryption.
• No formal penetration test has been performed.

If any of these are requirements for your business, contact us before you sign up.

9. Reporting a vulnerability

If you believe you have found a security issue, email [SECURITY EMAIL] with steps to reproduce. Please give us a reasonable window to fix it before disclosing publicly. We will acknowledge your report within [3 business days] and keep you updated until it is resolved.

Please do not run automated scans against production or access data that is not yours.