Security

Hosting & Compute

• Application servers run on Hostinger VPS (United States: Phoenix, AZ). All application logic, API endpoints, and background workers execute within this isolated environment.
• Database is hosted on Supabase PostgreSQL (United States). Database access is restricted to the application server IP via firewall rules and connection-level TLS.

Network Security

• Cloudflare provides DNS management, global CDN, DDoS protection (Layer 3/4/7), and Web Application Firewall (WAF) rules. All traffic between end users and our origin server is proxied through Cloudflare with strict TLS enforcement.
• UFW (Uncomplicated Firewall) is configured on the application server with a default-deny policy. Only ports 80 (redirected to 443), 443 (HTTPS), and 22 (SSH, key-only auth) are open to the public internet; a small set of additional ports is reachable only from a single authorized staging IP. All other inbound traffic is blocked.
• fail2ban monitors SSH authentication for brute-force attempts. The sshd jail bans an IP after 5 failed login attempts within a 5-minute window for 15 minutes. In addition, the application locks an account after 5 consecutive failed logins for 30 minutes.
• Server access is restricted to key-based SSH from authorized administrators. Application authentication events are written to an audit log and reviewed on an ongoing basis.

Data Residency

• Application servers run in the United States (Hostinger, Phoenix, AZ). The database is hosted on Supabase in the United States (AWS us-west-2, Oregon), with a Data Processing Agreement (DPA) covering data transfers.
• Stripe payment processing may involve data transfers to Stripe servers in the United States. Stripe maintains Binding Corporate Rules and Standard Contractual Clauses for lawful international data transfers.

Encryption at Rest

• ESX output files use the ESX container format's standard wrapping, which is required for Xactimate import compatibility; it is a format requirement, not an additional at-rest security control.
• W-9 tax identifiers are encrypted at rest with Fernet (AES-128-CBC) using a key held in environment configuration.
• Uploaded source PDFs are stored on the application server's disk. The PostgreSQL database, hosted by Supabase, provides encryption at the storage layer.

Encryption in Transit

• TLS 1.2 and 1.3 are used for all connections between end users and ESXPress (HTTPS); TLS 1.0 and 1.1 are disabled at the origin.
• HSTS (HTTP Strict Transport Security) is enabled with a max-age=31536000 directive, including includeSubDomains.
• Internal service-to-service communication (application server to Supabase, application server to Stripe API) is encrypted in transit with certificate validation.

Password & Token Security

• Passwords are hashed using bcrypt with a cost factor of 12. Passwords are never stored in plaintext, never logged, and never transmitted without TLS encryption.
• Authentication tokens use JWT with HS256 signing. The JWT lives only in browser storage and is sent in an Authorization header on every request; an esx_token presence cookie (no credentials) plus a SameSite=Strict CSRF cookie protect against forgery. Expiry is enforced server-side.
• API keys for programmatic access are generated with sufficient entropy (256-bit random) and stored as SHA-256 hashes. Keys are shown once at creation time; subsequent retrieval is impossible.

Authentication & Session Management

• Account lockout: After 5 consecutive failed login attempts, the account is locked for 30 minutes. This prevents brute-force attacks while avoiding permanent lockout from accidental mistypes.
• Session timeout: User sessions expire after a period of inactivity, 2 hours by default, configurable per account from 5 minutes to 12 hours. The countdown restarts every time the app is used, so an active session stays signed in; signing out only happens after a full stretch of inactivity. Sessions are tracked server-side and can be revoked individually from the Dashboard settings page.
• Device limits: Concurrent sessions are enforced per subscription tier. Session anomalies are logged server-side and available to administrators for review.

Rate Limiting & Abuse Prevention

• API endpoints: 60 requests per minute for anonymous traffic, 600 per minute per tenant for authenticated calls, and 60 per minute for API-key traffic, a tenant's keys share one bucket. Exceeding any limit returns HTTP 429 with aRetry-After header.
• Login endpoint: 20 requests per minute per IP. Combined with the account lockout policy, this makes credential-stuffing attacks impractical.
• Signup endpoint: 3 signups per day per IP to prevent automated account creation.

Web Application Defenses

• CSRF protection: All state-changing endpoints (POST, PUT, PATCH, DELETE) require a valid CSRF token. Tokens are issued per-session, bound to the user's identity, and validated server-side on every request.
• Content Security Policy (CSP): A restrictive CSP header is deployed with script-src, style-src, and connect-src limited to trusted origins. Inline scripts are minimized.
• Input validation: All user input, including uploaded PDFs, form fields, API payloads, and query parameters, is validated and sanitized server-side. SQL injection is prevented by SQLAlchemy parameterized queries.
• Tenant data isolation: Every database query is scoped by the authenticated tenant in the application layer, and cross-tenant access requires superadministrator privileges that are themselves audit-logged. Tenant isolation is enforced in the application layer.

SOC 2: CC6 Controls

ESXPress has implemented the Trust Services Criteria (TSC) Common Criteria 6 (CC6) controls from the AICPA SOC 2 framework. These controls address logical and physical access, system operations, change management, and risk mitigation:

• CC6.1: Logical Access Security: Unique user IDs, password complexity requirements, account lockout policies, and role-based access controls (RBAC).
• CC6.2: User Access Provisioning: Access is granted on a least-privilege basis. Administrative access is restricted to named individuals, and multi-factor authentication (TOTP) is available to enable on every account.
• CC6.3: Data Confidentiality: Encryption at rest and in transit, RLS on all tables, and data isolation between customer accounts.
• CC6.4: Change Management: All code changes go through pull request review, automated testing, and staged deployment. Infrastructure changes are managed via infrastructure-as-code with audit trails.
• CC6.6: Risk Mitigation: Regular dependency vulnerability scanning, automated security patch application, and documented incident response procedures.

Note: ESXPress is actively pursuing a formal SOC 2 Type II attestation. The CC6 controls listed above are implemented and operating. Contact hello@esxpress.org for our most recent self-assessment and auditor readiness status.

GDPR

• Data residency: Application servers run in the United States (Hostinger, Phoenix, AZ); the database is hosted on Supabase in the United States (AWS us-west-2, Oregon). Transfers are covered by a Data Processing Agreement (DPA) as described below.
• Data Processing Agreement (DPA): Available upon request for enterprise customers. Covers our role as a data processor, sub-processor disclosures, and data subject request handling procedures.
• Privacy-respecting analytics: We use privacy-respecting analytics (Plausible) and, after consent, Google Analytics (consent-mode default: denied). No behavioral advertising.
• Data subject rights: Users can export, correct, or delete their data at any time via the Dashboard or by emailing hello@esxpress.org. We respond to all data subject requests within 30 days.

PCI Compliance

• Stripe PCI-DSS Level 1: All payment processing is handled by Stripe, a PCI-DSS Level 1 certified service provider, the highest level of certification available. ESXPress never stores, processes, or transmits raw credit card data.
• Payment pages are served via Stripe Elements (iframes hosted by Stripe) or Stripe Checkout (fully hosted). No card data touches ESXPress servers at any point.

Backups

• Managed database backups: The database is backed up automatically as part of the managed hosting provider's standard offering, with backups retained per the provider's default retention schedule.
• User data exports: You can export your account data (profile, conversion history, API keys, webhooks, email-ingest tokens, and settings) at any time from the authenticated privacy export endpoint, or by contacting hello@esxpress.org. See our Privacy Policy for details on what the export includes.

Monitoring & Detection

• Application audit logging records authentication events, administrative changes, and file-access activity for review.
• fail2ban provides intrusion detection at the SSH authentication layer, automatically blocking IPs that exhibit brute-force behavior.
• Application health checks run continuously on all API endpoints. Degraded service triggers automated alerts to the engineering team.
• Dependency management: Third-party dependencies are kept up to date, and known high-severity vulnerabilities are addressed as quickly as the normal release process allows.

Incident Response

ESXPress maintains a documented incident response plan covering identification, containment, eradication, recovery, and post-incident review. In the event of a confirmed security incident affecting customer data, affected customers will be notified within 72 hours of confirmation, in compliance with GDPR Article 33 notification requirements.

How to Report

• Email: hello@esxpress.org
• PGP key: https://esxpress.org/security/pgp-key.asc (fingerprint 9901 2E5D 9661 CFF4 F816 AA41 0C76 E4C5 5B5E F4D0) for encrypted communication.
• Include a detailed description of the vulnerability, steps to reproduce, and any proof-of-concept code or screenshots. The more detail you provide, the faster we can triage and resolve the issue.

Our Commitment

• We will acknowledge your report within 3 business days and provide an initial assessment.
• We will keep you informed of our progress throughout the remediation process.
• We will not pursue legal action against researchers who act in good faith, follow this policy, and avoid harming users or degrading our services.
• We treat all vulnerability reports with strict confidentiality and will not share your identity without your permission.

Guidelines for Researchers

• Do not access, modify, or delete data that does not belong to you.
• Do not perform denial-of-service attacks, social engineering, or physical security testing.
• Stop testing and report immediately if you gain access to non-public data.
• Give us reasonable time to investigate and remediate before disclosing the vulnerability publicly.