Security
How we protect your account, data, and privacy at every layer.
Authenticated Access
Every dashboard and API route is protected by verified Firebase sessions.
Secure Sessions
HTTP-only cookies with server-side verification prevent session hijacking.
Encrypted Infrastructure
All data in transit and at rest is protected by industry-standard encryption.
1. Authentication
User identity is verified through Firebase Authentication, which supports email/password and Google Sign-In. All authentication operations (sign-up, login, password reset, email verification) are handled through Firebase’s secure infrastructure. Google Sign-In users bypass email verification since their email is already verified by Google.
2. Server-Side Session Security
After authentication, a secure session cookie (__session) is created using an HTTP-only, secure, SameSite-strict cookie. The server verifies this cookie using the Firebase Admin SDK on every protected request. Sessions that are expired, revoked, or belong to disabled accounts are immediately rejected.
3. Data Ownership & Access Control
Your projects are protected through authenticated access, ownership rules, secure sessions, and encrypted hosting infrastructure. Firestore security rules enforce that only the authenticated author can read or write their own projects, audits, and rewrite history. No other user or unauthenticated request can access your data.
4. Transport & Infrastructure Security
All traffic between your browser and our servers is encrypted with TLS (HTTPS). The application is hosted on Vercel, which provides automatic HTTPS, DDoS protection, and edge caching. Data stored in Google Cloud Firestore is encrypted at rest using Google-managed encryption keys.
5. Rate Limiting & Abuse Prevention
To protect the platform from abuse and ensure fair access, all AI processing endpoints are rate-limited using Upstash Redis. Rate limits are applied per-user and per-IP across analysis, rewrite, import, and deletion operations. If Upstash is unavailable, the system fails closed (denying requests) to prevent unmetered access.
6. Security Headers
The application sets defensive HTTP headers including Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Strict-Transport-Security to protect against common web vulnerabilities such as XSS, clickjacking, and MIME-type sniffing attacks.
7. Reporting Security Issues
If you discover a security vulnerability, please contact us immediately at support@retentionyt.com. We take all reports seriously and will respond promptly. Please do not publicly disclose the issue until we have had a chance to address it.