Security

Security should be specific, not a badge.

This page describes security controls that are implemented in CloserWin today, the responsibilities customers still own, and what CloserWin does not claim to have certified.

Updated September 2, 2026
Current security posture

CloserWin applies application-layer controls around authentication, tenant isolation, integration secrets, OAuth, webhooks and AI actions. Production also requires HTTPS and hardened configuration. This page deliberately avoids claiming certifications or audits that have not been completed.

1. Implemented controls

Password protectionPasswords are salted and hashed with PBKDF2-SHA256 using 600,000 iterations; raw passwords are not stored.
Session protectionSession tokens are random, stored server-side as hashes, and delivered in HttpOnly cookies. Production requires secure cookies over HTTPS.
CSRF defenseState-changing authenticated requests require a matching CSRF token tied to the active session.
Integration secret encryptionConnected-provider access tokens are encrypted before database storage using a separate integration-encryption secret.
OAuth state validationGoogle and Meta authorization flows use signed, time-limited OAuth state to protect tenant and user context.
Tenant isolationAuthenticated data queries are scoped to the active organization rather than relying on client-supplied organization IDs.
Rate limitingAuthentication, verification and recovery endpoints use rate limits to reduce brute-force and abuse risk.
Provider webhook verificationMeta webhook payloads are verified with the provider signing secret when Meta is configured.
Production configuration checksProduction startup validates HTTPS URLs, secure cookies, strong secrets, persistent database/Redis configuration and trusted hosts.
AuditabilityImportant authentication, connection and agent actions are written to audit records for operational review.

2. Browser and API hardening

CloserWin sends browser security headers intended to reduce clickjacking, MIME-type confusion, unnecessary browser capabilities and referrer leakage. The API is configured with trusted-host validation and explicit CORS origins, and authenticated API responses are treated as non-cacheable.

Production configuration requires HTTPS for both the public frontend and API URLs. HSTS is enabled only in production so local development is not locked to HTTPS.

3. Authentication and account recovery

Email verification is required before normal sign-in. Password-reset and email-verification tokens are randomly generated, stored as hashes, time-limited and single-use. A successful password reset invalidates existing user sessions.

CloserWin currently relies on provider/account security plus its own password/session controls; no public claim of built-in CloserWin MFA is made unless that feature is added and verified later.

4. Connected-provider security

Google and Meta integrations use their official authorization flows. Normal users are not asked to paste OAuth access tokens into the product UI. Stored integration tokens are encrypted before persistence and decrypted only when the backend needs to call the provider.

Meta inbound webhooks verify the X-Hub-Signature-256 signature when the Meta app secret is configured. Webhook subscription setup also requires the configured verification token.

5. AI safety controls

AI security is not only about model access. CloserWin keeps tenant-scoped context, uses exact/cautious contact memory resolution, retrieves business knowledge inside the active organization, and applies a second verification step to sensitive outbound claims depending on the configured intelligence level. Unsupported high-impact claims can be blocked and handed to a human instead of being sent automatically.

Autopilot execution also uses dispatch claims to reduce duplicate sends. This materially lowers duplicate-delivery risk but is not presented as a full exactly-once transactional outbox guarantee.

6. Data protection boundaries

Integration credentials are encrypted at the application layer. Passwords and session tokens are hashed. Customer conversation content, leads, deals and knowledge remain in the application database and should also be protected by the encryption, access controls and backup practices of the selected production infrastructure provider.

CloserWin does not claim end-to-end encryption of customer messages because connected providers and the CloserWin backend must be able to process message content to provide the service.

7. Customer responsibilities

  • Use strong, unique passwords and protect the email account tied to CloserWin.
  • Enable MFA on Google, Meta and other connected provider accounts where available.
  • Grant only the provider assets and permissions the workspace actually needs.
  • Remove users and disconnect integrations when access is no longer required.
  • Keep business knowledge accurate, especially prices, policies and availability.
  • Use Approval mode for sales scenarios that require human judgment or regulatory review.
  • Protect exported data, screenshots, browser sessions and devices outside CloserWin.

8. What CloserWin does not claim today

Unless and until separately completed and documented, CloserWin does not claim SOC 2 certification, ISO 27001 certification, PCI DSS certification as a merchant storing card data, a completed independent penetration test, a formal public bug-bounty program, or a contractual uptime SLA. Paddle handles normal payment-card entry for CloserWin checkout.

9. Vulnerability disclosure

If you believe you found a security issue, do not access data that is not yours, do not disrupt the service and do not publicly disclose exploit details before the issue can be reviewed. Provide a clear description, affected URL/component, reproduction steps and potential impact through Plan0101's official contact channel at https://plan0101.com.

Good-faith reports that avoid privacy violations, destructive testing and extortion will be reviewed as product security reports.

10. Incident response

Security incidents should be contained, investigated and documented, with affected credentials rotated where appropriate. If an incident creates a legal notification obligation, notices should be made to affected customers or authorities within the time required by applicable law.

Translations are provided for convenience. If a translated version conflicts with the English version, the English version controls to the extent permitted by applicable law.