Security Policy

1. Overview & Commitment

1.1 Mailxify is committed to protecting the personal data of its Users and the Recipient data processed on their behalf. This Security Policy describes the actual technical and organizational security measures that are currently in place, as verified at the time of this Policy's effective date. Mailxify will update this Policy when security controls are materially changed, added, or removed.

1.2 Accuracy Principle. This Policy describes only controls that are currently operational and verified. It does not describe intended future controls as current capabilities. Controls that are planned but not yet implemented are described only in Section 15 (Future Features), clearly labelled as planned.

1.3 No Absolute Security. No security system can provide absolute protection against all possible threats. Mailxify aims to implement controls appropriate to the risk level presented by the data we process, and to continually improve our security posture. Users are also responsible for protecting their own Account credentials and for taking appropriate security precautions at their own end.

1.4 Applicable Standards. Mailxify's security practices are designed to meet the requirements of the Information Technology (Reasonable security practices and procedures and sensitive personal data or information) Rules, 2011 (SPDI Rules) issued under the Information Technology Act, 2000, and to align with the intended requirements of the Digital Personal Data Protection Act, 2023.

2. Architecture & Infrastructure

2.1 Hosting. The Mailxify application is hosted on Vercel Inc.'s cloud infrastructure. Vercel is a globally recognized cloud hosting provider with SOC 2 Type II certification for its own infrastructure operations. Vercel's security posture is described in Vercel's own Trust documentation.

2.2 Serverless Architecture. The application is deployed as a Next.js serverless application. Serverless architecture reduces attack surface by eliminating persistent long-running server processes that could be compromised between requests. Each request is handled in an isolated execution context.

2.3 Database. Mailxify uses Neon Inc.'s managed serverless PostgreSQL database service. Neon operates on AWS infrastructure in the ap-southeast-1 (Singapore) region. Neon provides encryption at rest for database storage volumes. Neon's security posture is described in Neon's own documentation.

2.4 No Custom Server Infrastructure. Mailxify does not maintain self-operated physical or virtual servers. All infrastructure is managed by certified cloud providers, reducing Mailxify's exposure to physical security risks and infrastructure-level vulnerabilities.

2.5 Separation of Concerns. The application tier (Vercel) and the data tier (Neon) are physically and logically separated. The application server communicates with the database only over authenticated, encrypted connections.

3. Authentication & Access Control

3.1 Authentication Framework. Mailxify uses the better-auth authentication library to manage User authentication. This framework provides a production-grade implementation of session management, credential handling, and security token generation.

3.2 Password Security.

• User passwords are never stored in plaintext or in a reversible encrypted form;
• Passwords are processed through bcrypt (or equivalent industry-standard one-way hash function with an adaptive work factor) before storage;
• The stored value is an irreversible hash — Mailxify personnel cannot retrieve your original password;
• Password reset is performed exclusively through a time-limited, single-use reset link sent to your verified email address; reset links expire within a configured short window.

3.3 Session Management.

• Upon successful authentication, a session is created and a cryptographically signed session token is issued;
• Session tokens are stored in the User's browser as httpOnly cookies, preventing client-side JavaScript from accessing the token (reducing XSS session theft risk);
• Sessions have a configured expiry. Inactive sessions are automatically expired;
• Session tokens are immediately invalidated upon logout;
• Session records in the database include the IP address and User Agent string at the time of creation, enabling anomaly detection (e.g., session usage from an unexpected location).

3.4 Brute Force Protection. Rate limiting is applied to authentication endpoints (login and registration) to limit the rate at which automated credential-guessing attacks can be attempted. Failed authentication attempts may trigger delays or temporary lockout of the targeted Account.

3.5 Multi-Factor Authentication. Multi-factor authentication (MFA/2FA) is not currently implemented. MFA for User Accounts is a planned future security enhancement. Users should ensure their registered email account is protected by MFA, as it is used for Account recovery.

4. Authorization & Workspace Isolation

4.1 Server-Side Authorization. All data access in the Mailxify application is governed by server-side authorization checks. Client-side role assertions or access parameters provided in HTTP requests are treated as untrusted. Authorization for every data operation (read, write, update, delete) is independently verified on the server against the authenticated User's session and their recorded permissions.

4.2 Workspace Scoping. All database queries that access User Content (Contacts, Campaigns, Mailboxes) are scoped to the authenticated User's specific Workspace. The application enforces that:

• A User can only access Workspaces for which they hold an active membership record in the database;
• Cross-workspace data access is not possible through normal application operations;
• Workspace membership is verified on every request, not cached from a prior check.

4.3 Role-Based Access Control. The application implements role-based access control (RBAC) at two levels:

• Account-level roles: "USER" (standard access) and "ADMIN" (administrative access to Mailxify's own operational tools); and
• Workspace-level roles: "OWNER" (full administrative control of the Workspace) and "MEMBER" (access limited to Workspace features without administrative privileges).

Workspace Owners cannot grant Members permissions that exceed their own. Administrative features are only available to Accounts with the ADMIN role as assigned in the Mailxify system.

4.4 Defense in Depth. Authorization checks are implemented at the API layer and are not solely dependent on UI restrictions. Even if a User attempts to access a restricted resource directly via an API call bypassing the user interface, the server-side authorization check will reject the request.

5. Encryption & Data in Transit

5.1 TLS Enforcement. All communications between Users' browsers and the Mailxify application are encrypted using Transport Layer Security (TLS) version 1.2 or higher. TLS termination is performed at Vercel's edge network. HTTP connections (unencrypted) are automatically redirected to HTTPS.

5.2 Database Connection Encryption. The connection between the Mailxify application server and the Neon database is encrypted using TLS, enforced by Neon's connection requirements (sslmode=require; channel_binding=require). No plaintext database connections are permitted.

5.3 Cookie Security. Authentication cookies are set with the Secure flag (transmitted only over HTTPS) and the httpOnly flag (not accessible to client-side JavaScript). The SameSite attribute is used to mitigate cross-site request forgery (CSRF) risks.

5.4 Encryption at Rest. Mailxify's database storage is encrypted at rest by Neon's infrastructure (using AES-256 or equivalent, as managed by Neon on AWS). Application-level encryption of specific sensitive fields (such as future OAuth tokens) is described in Section 15.

6. Database Security

6.1 Access Control. The Neon database is not publicly accessible without valid authenticated credentials. Database connection strings (including authentication credentials) are stored as environment variables within Vercel's encrypted environment configuration, not in source code or version control.

6.2 Parameterized Queries & ORM. All database queries in the Mailxify application are constructed using the Drizzle ORM, which employs parameterized queries and prepared statements. Parameterized queries prevent SQL injection attacks by ensuring that user-supplied values are treated as data parameters, never as executable SQL code.

6.3 Minimal Privilege. The database user credential used by the application is configured with the minimum permissions necessary for application operations (read/write access to application tables). It does not have schema-altering permissions in the production environment.

6.4 Database Backups. Neon provides automated database backup and point-in-time recovery capabilities as part of its managed database service. Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO) are governed by Neon's service terms and SLAs. Mailxify relies on Neon's backup infrastructure and does not maintain independent database backups at this time.

7. Application-Level Security

7.1 Input Validation. User-supplied inputs (form fields, API parameters, URL query parameters) are subject to server-side validation before processing or storage. Validation includes length limits, type checks, and format validation where applicable. Client-side validation is used for user experience enhancement but is not relied upon as a security control.

7.2 Cross-Site Scripting (XSS) Prevention. The application is built using React (via Next.js), which automatically escapes dynamic content rendered to the browser to prevent reflected and stored XSS attacks. Content Security Policy (CSP) headers are configured to restrict the sources from which scripts, styles, and other resources may be loaded.

7.3 Cross-Site Request Forgery (CSRF) Prevention. Authentication cookies are configured with SameSite attributes to mitigate CSRF risks. API routes that perform state-changing operations require authenticated sessions and are protected against cross-origin forgery.

7.4 Legal Form Abuse Prevention. The public-facing legal request forms (grievance, privacy requests, abuse reports) are protected by rate limiting and CAPTCHA-like mechanisms (where implemented) to prevent automated mass submission. Submitted data is validated server-side before storage.

7.5 Error Handling. Application errors are logged internally but error messages exposed to users are generic and do not expose internal system details, stack traces, database query structures, or other sensitive technical information.

8. Secrets & Credential Management

8.1 All sensitive configuration values — including database connection strings, authentication secret keys, and any third-party API keys — are stored as environment variables within Vercel's encrypted environment configuration system. These values are:

• Not hardcoded in application source code;
• Not committed to version control repositories;
• Accessible only to the application runtime environment, not exposed to client-side code;
• Rotatable without requiring code changes.

8.2 The .env file (if used in local development) is listed in the application's .gitignore configuration to prevent accidental commit of local secrets.

9. Rate Limiting & Abuse Prevention

9.1 Mailxify applies rate limiting at the following levels:

• Authentication endpoints: Login and registration attempts are rate-limited to prevent credential stuffing and brute-force attacks;
• Legal form submissions: Public-facing form submission endpoints (grievance, privacy requests, abuse reports) are rate-limited to prevent automated mass abuse;
• API endpoints generally: General API rate limiting is enforced at the application layer.

9.2 Vercel's infrastructure provides DDoS mitigation at the network layer as part of its platform services. Large-scale distributed denial of service attacks against the Service's infrastructure are mitigated by Vercel's network capabilities.

10. Logging & Audit Trails

10.1 Mailxify maintains the following logs for security and operational purposes:

• Application error logs: Errors encountered during request processing are logged with relevant context (excluding sensitive user data) for debugging and security monitoring;
• Authentication event logs: Successful and failed login attempts, session creation, and logout events are recorded to support detection of unauthorized access attempts;
• Request metadata logs: HTTP request paths, response codes, timestamps, and IP addresses are logged by Vercel's infrastructure for operational and security purposes.

10.2 Security logs are retained for a period of ninety (90) days or as required by applicable law (including CERT-In directions), whichever is longer, then automatically deleted.

10.3 Logs are not used for marketing, profiling, or any purpose other than security monitoring, debugging, and legal compliance. Log access is restricted to authorized personnel.

11. Dependency Management

11.1 The Mailxify application relies on a number of open-source software libraries and Node.js packages as dependencies. Mailxify monitors these dependencies for publicly disclosed security vulnerabilities using available tooling (including npm audit and GitHub Dependabot alerts where configured).

11.2 Security-relevant dependency updates (patches for known vulnerabilities) are reviewed and applied with reasonable promptness following disclosure. Critical security patches are prioritized.

11.3 Mailxify uses a pinned dependency version approach in its production build to ensure that unexpected dependency changes do not introduce vulnerabilities between deployments.

12. Administrative Access

12.1 Administrative access to Mailxify's production environment is limited to the minimum number of authorized personnel necessary for operations, currently restricted to the founding team.

12.2 Access to production infrastructure (Vercel dashboard, Neon console) is protected by strong authentication credentials and, where available, multi-factor authentication.

12.3 Mailxify's in-application ADMIN role provides access only to Mailxify's own operational tools (e.g., launch readiness dashboard, legal request management). ADMIN role holders cannot access the content of other Users' Workspaces, Campaign templates, or Contact data beyond what is technically necessary to investigate a specific abuse complaint.

13. Development Practices

13.1 Security considerations are incorporated into the development process for new features and changes. Before deploying material changes, Mailxify reviews the changes for common security issues including:

• Authorization bypass vulnerabilities (does the new endpoint enforce workspace isolation and session authentication?);
• Input validation gaps (is all user-supplied input validated before processing?);
• Injection vulnerabilities (are all database operations using parameterized queries?);
• New secrets introduced into the codebase (are they stored as environment variables, not hardcoded?); and
• New third-party dependencies (are they from reputable sources and recently maintained?).

13.2 Development and production environments are separated. Development occurs against a separate development database instance, ensuring that production user data is not accessible during development.

14. Incident Response

14.1 Incident Definition. A security incident is any confirmed or credibly suspected event that compromises the confidentiality, integrity, or availability of personal data or the Service.

14.2 Detection. Mailxify monitors application error logs, authentication anomalies, and Vercel/Neon infrastructure alerts for indicators of security incidents.

14.3 Containment. Upon confirmation of a security incident, Mailxify will take prompt action to contain the incident, including (as appropriate) revoking compromised credentials, blocking malicious IP addresses, rolling back affected deployments, or suspending specific application functionality.

14.4 User Notification. In the event of a personal data breach that is reasonably likely to result in a risk to the rights or interests of affected Users or Recipients, Mailxify will notify affected individuals without undue delay, to the extent that their identity and contact information can be determined. Notification will include: (a) the nature of the incident; (b) the categories of data affected; (c) the likely consequences; and (d) the measures taken or proposed.

14.5 Regulatory Reporting. Where required by CERT-In directions (Information Technology (The Indian Computer Emergency Response Team and Manner of Performing Functions and Duties) Rules, 2013), Mailxify will report qualifying security incidents to CERT-In within the required timeframe (currently, within six (6) hours of becoming aware, for qualifying incidents under the 2022 CERT-In directions). Mailxify will also comply with any data breach notification obligations under the DPDPA when those provisions become operational.

14.6 Post-Incident Review. Following containment and recovery from a significant security incident, Mailxify will conduct an internal post-incident review to identify root causes and implement preventive measures.

15. Security for Future Features

The following security controls are planned but not yet implemented. They are described here as forward-looking commitments, not current capabilities:

• Gmail OAuth Token Encryption (Planned): When the Gmail Integration is activated, OAuth access tokens and refresh tokens will be encrypted at the application layer using AES-256-GCM symmetric encryption before storage in the database. Encryption keys will be managed separately from encrypted data. This control will be in place before any production Gmail OAuth tokens are stored.
• Multi-Factor Authentication (Planned): MFA/2FA for User Accounts is a planned future security enhancement. When implemented, Users will be able to enable MFA via the Account Settings.
• Advanced Audit Logging (Planned): More granular audit logging (logging of specific CRUD operations on sensitive data) is a planned enhancement. Currently, logging is at the request level rather than at the database operation level.

16. Limitations & User Responsibilities

16.1 Mailxify's security controls protect data within Mailxify's systems. Users are also responsible for their own security practices, including:

• Using a strong, unique password for their Mailxify Account;
• Not sharing Account credentials with unauthorized parties;
• Protecting the email account associated with their Mailxify Account (as it is used for Account recovery);
• Using secure devices and network connections when accessing the Service;
• Immediately reporting suspected unauthorized access to their Account to support.mailxify@gmail.com.

16.2 Mailxify does not hold, and does not represent that it holds, ISO 27001, SOC 2, or other independent third-party security certifications. Our infrastructure providers (Vercel and Neon) hold their own certifications, which cover their infrastructure but do not constitute a certification of Mailxify's application or processes.

17. Vulnerability Disclosure

17.1 If you discover a security vulnerability in the Mailxify platform, we strongly encourage responsible disclosure. Please report the vulnerability by email to support.mailxify@gmail.com with the subject line "Security Vulnerability Report".

17.2 Please provide sufficient detail to allow Mailxify to reproduce and assess the vulnerability, including: (a) a description of the vulnerability; (b) the affected URL, endpoint, or component; (c) steps to reproduce; and (d) your assessment of the potential impact.

17.3 Mailxify will acknowledge receipt of a vulnerability report within forty-eight (48) hours, and will provide a substantive response within fourteen (14) days. Mailxify will treat all responsibly disclosed vulnerability reports with confidentiality.

17.4 Mailxify does not operate a formal bug bounty programme at this time. However, responsible disclosure of significant vulnerabilities will be acknowledged with gratitude, and Mailxify will use reasonable efforts to remediate confirmed vulnerabilities in a timely manner.