Security Policy

This page describes security practices for Mydle. It is not a formal certification or SOC report. We update it as the platform matures.

1. Application security

• HTTPS in production for application traffic
• Password hashing via our authentication provider (Better Auth)
• Session cookies with secure attributes in production
• Email verification required for email/password sign-in in production
• CSRF and origin protections on sensitive auth flows
• SSRF protections on outbound monitoring HTTP checks
• Feature entitlements enforced server-side

2. Infrastructure

• Managed Postgres (Neon) with TLS
• Distributed rate limiting via Redis when configured
• Background workers on Trigger.dev for continuous checks
• Environment validation that fails closed in production

3. Access control

• Workspace membership and role checks on server actions
• Platform admin routes restricted to admin roles
• Secrets stored in environment configuration — never in client code

4. Monitoring and response

• Structured logging with secret redaction
• Optional Sentry error reporting when configured
• Health endpoints for liveness and readiness
• Operational alerts for critical platform failures

5. Data handling

See Privacy and Data Processing. Customers should not store payment card PAN data in Mydle; cards are handled by the payment provider when billing is enabled.

6. Responsible disclosure

Report suspected vulnerabilities to security@mydle.app. Please do not publicly disclose until we have had a reasonable opportunity to investigate and remediate.

7. Limitations (honest)

• We are an early-stage SaaS — not every enterprise control is shipped
• SSO is Enterprise-only and requires validation with the customer IdP
• Formal penetration-test reports are not currently available
• Customer misconfiguration of monitoring targets remains your responsibility