Security

Hosting & Compute

• Application servers run on Hostinger VPS (Germany datacenter, Frankfurt region). 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. All other inbound ports are blocked.
• fail2ban monitors authentication endpoints for brute-force attempts. After 5 failed login attempts from a single IP within a 10-minute window, the IP is banned for 30 minutes. Repeated offenses escalate to permanent bans.
• auditd logs authentication events and configuration changes on the application server. Access and activity are logged and reviewed on an ongoing basis.

Data Residency

• Application servers run in Germany (Hostinger). The database is hosted on Supabase in the United States, 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 are encrypted at rest with industry-standard encryption.
• Uploaded source files (PDFs) are stored at rest on the managed database, which provides encryption at the storage layer.

Encryption in Transit

• TLS 1.3 is enforced for all connections between end users and ESXPress. TLS 1.2 is supported only as a fallback; TLS 1.0 and 1.1 are disabled entirely at the Cloudflare edge.
• 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) uses TLS 1.3 exclusively 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. Tokens are issued as HTTP-only, Secure, SameSite=Lax cookies. Token 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 30 minutes of inactivity, with an absolute maximum session length of 12 hours. Active sessions are tracked server-side and can be revoked individually from the Dashboard settings page.
• Device limits: Concurrent sessions are enforced per subscription tier. Suspicious session patterns (e.g., simultaneous access from geographically distant IPs) trigger automated review.

Rate Limiting & Abuse Prevention

• API endpoints: 600 requests per minute per IP address. Exceeding this limit returns HTTP 429 with aRetry-After header. Authenticated users have higher per-account limits based on subscription tier.
• 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.
• Row-Level Security (RLS):Every database table has RLS policies that enforce per-user access at the PostgreSQL level. Even if the application layer were bypassed, a user cannot access another user's data.

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 [email protected] for our most recent self-assessment and auditor readiness status.

GDPR

• Data residency: Application servers run in Germany (Hostinger); the database is hosted on Supabase in the United States. 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.
• No third-party tracking: ESXPress does not use tracking cookies, analytics cookies, advertising pixels, or any form of behavioral tracking. The only cookies we set are strictly necessary for authentication and security (JWT tokens, CSRF tokens).
• Data subject rights: Users can export, correct, or delete their data at any time via the Dashboard or by emailing [email protected]. 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: Enterprise customers can request an encrypted export of all their data at any time. Contact [email protected] to initiate.

Monitoring & Detection

• auditd provides real-time file integrity monitoring for critical system files, configuration files, and application binaries. Any unauthorized modification generates an immediate alert.
• fail2ban provides intrusion detection at the 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 scanning: All third-party dependencies are scanned weekly for known vulnerabilities (CVEs). Critical patches are applied within 48 hours; high-severity patches within 7 days.

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: [email protected]
• PGP key: Available upon request 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 48 hours 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.