Security & Compliance

1. Data encryption

• At rest (application secrets): bot tokens, OAuth refresh tokens, and Stripe customer secrets are encrypted with AES-256-GCM (authenticated encryption, 96-bit IV per record) by our application layer before being written to the database. The encryption key is stored in the host's environment, never in the database.
• At rest (backups): PostgreSQL and Redis backup dumps are encrypted with GPG (AES-256 cipher) before being uploaded off-host. Integrity verified via SHA-256.
• In transit: all client traffic is TLS 1.3 via Cloudflare. Internal API ↔ bot-engine traffic uses a shared BOT_ENGINE_SECRET with timing-safe comparison; the routes are not exposed to the public internet.
• Passwords: bcrypt cost 14 (industry-standard for 2026). User sessions use HttpOnly + Secure + SameSite=Lax cookies; tokens never leave the cookie jar.

2. Access controls

• Production access limited to the founding engineer (Alex). MFA is enabled on the critical accounts that support it (Stripe, Cloudflare). Hetzner, the Discord Developer Portal, and the self-hosted Gitea instance use strong unique passwords stored in a password manager.
• Database access is scoped per service (api, bot-engine) via least-privilege Postgres roles. Schema migrations follow a pre-flight safety scanner (backup + dry-run) documented in our runbook.
• Secret rotation on shared secrets (BOT_ENGINE_SECRET, JWT_SECRET, ENCRYPTION_KEY) is performed manually when needed. A documented rotation procedure exists in the runbook; we do not currently enforce a fixed yearly rotation cadence.
• JWT tokens carry an audience claim (wize-api) and HS256 signature. Refresh tokens are single-use (rotation on every refresh) with a tokenVersion on the user record for instant revocation.

3. Subprocessors

We rely on the following third parties to operate the service. Each one has its own security and compliance posture; click through for their respective documentation.

Stripe processes card numbers — we never see the PAN, only a Stripe customer ID. User-provided data shipped to AI subprocessors (Vertex AI / Gemini) is restricted to the prompt context for that single inference. We rely on Google's Vertex AI data governance commitments (see Vertex AI documentation) which state that customer prompts are not used to train Google's foundation models.

4. Backups & retention

• PostgreSQL: daily encrypted dump (GPG with AES-256 cipher) uploaded to S3-compatible off-host cold storage (Backblaze B2, separate provider from the application host). SHA-256 integrity verified per upload.
• Redis: daily snapshot, same encryption pipeline.
• Retention: daily backups kept ~30 days; weekly and monthly snapshots are produced and stored alongside.
• Backup integrity checks: a monthly dry-run script verifies that the latest backup can be decrypted and that its dump structure is valid (we do not perform a full end-to-end restore drill at this stage — that is a planned milestone once we have paying customers).
• Soft-delete window: when a user removes a bot from a server, the configuration is kept for 14 days and is restorable in one click. After 14 days, the row is hard-deleted.
• Account deletion: on user request via DELETE /api/users/account, the account is soft-deleted immediately: PII fields (email, name, Discord identifiers, MFA secrets, OAuth tokens) are scrubbed in the same database transaction; all sessions are revoked via tokenVersion increment. Financial records (invoices, payments, payouts) are preserved for 10 years per FR accounting law (Code de commerce L123-22).

5. Application security

• Rate limiting: 4-tier rate limit (global, per-IP, per-user, per-route) on the public API. Auth endpoints have a tighter ceiling (5 login attempts / IP / 15 min).
• Headers: Content-Security-Policy, Strict-Transport-Security (2-year max-age, includeSubDomains, preload), X-Frame-Options: DENY, X-Content-Type-Options: nosniff.
• SSRF protection: outbound webhook URLs validated against a deny-list (private IP ranges, link-local, metadata endpoints).
• Input validation: all API payloads validated against shared schemas before reaching business logic. SQL injection blocked by Prisma's parameterised queries (no raw SQL in user-facing routes).
• Logging hygiene: structured logging via Pino with explicit redaction of password, token, authorization, discordToken, telegramToken, and any field with secret in the name. Application logs stay on-host. Errors are forwarded to Sentry for crash reporting; request context (URL, status code, stack trace) is captured but sensitive header values are scrubbed by our Pino redaction layer before reaching Sentry.

6. Incident response

We treat any suspected breach with the following playbook:

1. Detect — Sentry alerts, anomaly thresholds, fail2ban triggers.
2. Contain — rotate the relevant secret immediately; suspend affected accounts if needed.
3. Eradicate — patch the root cause; deploy fix through the standard test gate (no shortcuts).
4. Notify — affected users within 72 hours if personal data was accessed (RGPD article 33). CNIL (FR data protection authority) within the same window.
5. Post-mortem — public summary published within 14 days unless investigation is ongoing.

We have not had a security incident as of the date of this page. If you discover a vulnerability, please email [email protected] — we respond within 48 hours and follow responsible disclosure.

7. Compliance status & roadmap

• RGPD: Astero implements the core GDPR rights — access (data export endpoint), deletion (account delete with PII scrub), portability (JSON export of user data), session revocation. See Privacy Policy for processing details and how to exercise your rights. Continuous improvements are ongoing.
• DPA: a Data Processing Agreement is not yet pre-drafted as a template. For ENTERPRISE customers requiring one, we can prepare a contract on a case-by-case basis — contact [email protected].
• SOC2 Type 1: not certified. We will pursue certification once Astero reaches a customer base where it materially matters (rough target: 100 paying customers).
• ISO 27001: not on the roadmap at this stage.
• Company status: Astero is operated as a French micro-entreprise based in Marseille. SIRET registration is in progress at the time of writing (see Mentions légales).

8. Contact

Security questions: [email protected]
Privacy / DPA: [email protected]
Legal: [email protected]