Security Practices

Effective date: March 31, 2026

Security is a foundational requirement for a platform that processes your product catalog, integrates with your storefronts, and generates content on your behalf. This page describes the technical and organizational controls we apply to protect your data and the EcomIQX platform. We aim to be specific about what we do without overstating our posture.

If you have a security concern or want to report a vulnerability, contact us directly at [email protected].

1. Infrastructure Security

1.1 Hosting and Network Isolation

The EcomIQX platform runs on containerized infrastructure using Docker. Production services are deployed within a private network where application components communicate over internal interfaces not exposed to the public internet. Only the services that require public access — the application frontend and API gateway — are exposed through controlled ingress points.

Internal services, including the PostgreSQL database, Redis cache, and background job worker, are bound to internal network interfaces only. Direct access to these services from outside the deployment environment is not permitted.

1.2 Container Security

Each service runs in its own isolated container with the principle of least privilege applied to process permissions and filesystem access. Containers run as non-root users where technically feasible. Dependencies are pinned to specific versions and reviewed regularly for known vulnerabilities. We monitor upstream security advisories for the key components in our stack: PostgreSQL, Redis, Node.js, and Bun.

1.3 Database and Storage Isolation

Customer data is stored in a shared PostgreSQL 16 database with row-level and organization-level logical isolation enforced by the application layer. Every query is scoped to the authenticated organization — no query pattern allows one tenant to access another's data. Connection pooling is handled by PgBouncer to manage database concurrency safely.

File and asset storage uses an S3-compatible object store (AWS S3 in production). Storage buckets are not publicly accessible. Files are served through short-lived pre-signed URLs with configurable expiration, ensuring that storage paths cannot be guessed or enumerated.

2. Data Encryption

2.1 Encryption in Transit

All data transmitted between your browser and the EcomIQX platform is encrypted using TLS 1.2 or higher. We enforce HTTPS for all application traffic and do not permit unencrypted HTTP connections. Connections that arrive over plain HTTP are redirected to HTTPS automatically.

Internal service-to-service communication within our production network uses encrypted channels for sensitive data paths. API requests from the application server to AI providers (Anthropic, OpenAI) and third-party services are made exclusively over TLS.

2.2 Encryption at Rest

Data at rest is encrypted using AES-256 at the storage layer. This applies to:

• PostgreSQL database volumes — encrypted at the block storage level in production
• S3-compatible object storage — server-side encryption enabled for all stored objects
• Backup snapshots — encrypted using the same mechanisms as primary storage

Sensitive application-level secrets — including third-party integration OAuth tokens, API keys, and webhook signing secrets — are stored encrypted in the database rather than in plaintext fields.

3. Authentication and Access Control

3.1 Password Security

Passwords are hashed using Argon2id, the winner of the Password Hashing Competition and the current industry recommendation for password storage. Argon2id is configured with memory-hard parameters that make brute-force and GPU-accelerated cracking attacks computationally expensive. We never store plaintext passwords at any point in the authentication flow.

3.2 OAuth Authentication

EcomIQX supports sign-in via Google and GitHub using the OAuth 2.0 protocol. When you authenticate through an OAuth provider, we receive only the minimum profile information required to create or identify your account (name, email address, and provider-issued user identifier). We store an opaque reference to the OAuth provider rather than credentials, and we do not have access to your OAuth provider account password.

3.3 Session Management

Authenticated sessions are managed server-side using session tokens stored in Redis. Session identifiers are transmitted to your browser exclusively via httpOnly, Secure cookies, which prevents client-side JavaScript from accessing the token and mitigates cross-site scripting (XSS) session hijacking attacks. Sessions are bound to a reasonable inactivity timeout and are invalidated server-side upon explicit sign-out.

3.4 Role-Based Access Control

Within an organization workspace, access is governed by four distinct roles with progressively scoped permissions:

• Owner — full administrative control, including billing management, workspace deletion, and member management. Only one owner per workspace.
• Admin — can manage team members, configure integrations and connectors, and access all product and content features. Cannot access billing or transfer ownership.
• Operator — can use all content and AI features, run jobs, manage products, and publish content. Cannot manage team members or integration credentials.
• Viewer — read-only access to product data, analytics, and generated content. Cannot trigger actions or modify any data.

Role checks are enforced at the API layer on every authenticated request. Role assignments are managed by organization owners and admins and are logged for audit purposes.

4. Application Security

4.1 Input Validation

All API inputs are validated at the boundary using Zod schemas before any application logic is executed. Every tRPC procedure defines a strict input schema; requests that do not conform to the schema are rejected with a structured error response. This validation applies to field types, string lengths, enumeration values, and structural shape — eliminating a broad class of injection and type confusion attacks at the input boundary.

4.2 Type-Safe API Layer

The application uses tRPC for all client-server communication. tRPC provides end-to-end TypeScript type safety from the API procedure definition through to the frontend caller, which structurally prevents a category of mismatched payload bugs that can otherwise create exploitable edge cases. There are no untyped REST endpoints that accept arbitrary payloads.

4.3 SQL Injection Prevention

All database access is performed through Drizzle ORM with parameterized queries. Raw SQL string concatenation is not used in the application codebase. Drizzle constructs parameterized statements for all queries, ensuring that user-supplied data is never interpreted as SQL syntax.

4.4 CSRF Protection

State-mutating API operations require an authenticated session and are scoped to the tRPC API layer. The combination of httpOnly session cookies (not accessible to JavaScript), origin validation on API requests, and the structured tRPC client — which does not follow cross-origin redirects — provides defense against cross-site request forgery in the application's threat model.

4.5 XSS Prevention

The EcomIQX frontend is built with Vue 3 and Nuxt 4, which apply automatic HTML escaping to all template bindings by default. Dynamic HTML rendering via v-html is avoided in the application codebase except where strictly necessary and sanitized. The httpOnly cookie policy for session tokens means that even if an XSS vulnerability were introduced, session tokens could not be exfiltrated by injected scripts.

4.6 Dependency Management

We review third-party dependencies for known vulnerabilities using automated scanning as part of our development workflow. Dependencies are updated regularly, and critical security patches are applied on an expedited basis. We aim to keep the dependency surface area minimal.

5. AI Data Security

5.1 What Data Is Sent to AI Providers

AI features — including content rewriting, translation, keyword extraction, and the Copilot — require sending your product data to third-party AI model providers. The data transmitted consists of:

• Product titles, descriptions, and other catalog fields submitted for processing
• System prompts and task instructions constructed by EcomIQX to instruct the models
• Contextual metadata required to produce useful outputs (e.g., target language, keyword targets)

We do not send passwords, payment details, session tokens, or other authentication credentials to AI providers. We do not send data that is not necessary to complete the requested AI operation.

5.2 Model Training Opt-Out

Anthropic (Claude models) and OpenAI both maintain API usage policies under which customer API data is not used to train their models by default for API customers operating under standard business terms. EcomIQX uses these providers exclusively via their API interfaces. Your product data submitted for processing is not used to train AI models by these providers.

You should review Anthropic's and OpenAI's current API usage policies directly for the latest terms, as provider policies may change over time and are governed by their agreements, not ours.

5.3 AI Observability (Langfuse)

We use Langfuse for AI observability: logging prompts, model responses, latency, and token costs for quality assurance, debugging, and cost management. Langfuse logs are associated with your organization's workspace and retained for up to 90 days. Access to Langfuse is restricted to EcomIQX engineering and operations staff. These logs are not shared with third parties beyond Langfuse's hosting service.

5.4 Provider Security Certifications

Our primary AI providers maintain recognized security certifications and compliance programs:

• Anthropic — maintains SOC 2 Type II certification and publishes a security overview at their trust portal
• OpenAI — maintains SOC 2 Type II certification and is ISO 27001 certified

6. Payment Security

All payment processing is handled exclusively by Stripe, a PCI DSS Level 1 certified payment processor. EcomIQX does not collect, transmit, process, or store credit card numbers, CVV codes, or other raw payment credentials on our infrastructure at any point in the transaction flow.

Payment details are collected on Stripe's hosted checkout page (Stripe Checkout). When you initiate a subscription, you are redirected to a Stripe-hosted page where payment information is entered directly into Stripe's environment. Card numbers, CVVs, and bank details never pass through EcomIQX servers or frontend code. We receive only a Stripe payment method token and billing metadata (subscription status, plan, last four digits of the payment method) for display and account management purposes.

This architecture means EcomIQX is outside the PCI DSS cardholder data environment for card number handling. Stripe's compliance documentation is available at stripe.com/docs/security.

7. Third-Party Integrations

7.1 OAuth-Based Connector Access

Integrations with Shopify, WooCommerce, Google Search Console, Google Merchant Center, and Google Analytics are established using OAuth 2.0. When you authorize a connector, EcomIQX receives an access token scoped to the specific permissions you grant. We request only the minimum scopes necessary for the integration's stated functionality — we do not request write access when read access is sufficient, and we do not request access to data unrelated to catalog and performance data.

7.2 Token Storage

OAuth access tokens and refresh tokens for third-party integrations are stored encrypted in the database using AES-256-GCM. The encryption key is managed separately from the database via environment configuration, ensuring that database-level access alone is not sufficient to read token values. Tokens are decrypted in application memory only at the time they are needed for an API call and are not logged or written to secondary storage in plaintext. You can revoke EcomIQX's access to any integration at any time, both from within the EcomIQX settings and directly from the connected platform's authorization settings.

7.3 Webhook Security

Inbound webhook events from integrated platforms are validated using provider-issued signing secrets. Each incoming webhook payload is verified against its HMAC signature before processing, ensuring that we only process events originating from the declared provider and not forged requests.

8. Data Backup and Recovery

8.1 Database Backups

The PostgreSQL database is backed up on a scheduled basis. Backups are encrypted using the same AES-256 controls applied to primary storage and are retained for a rolling window of at least 30 days. Backup files are stored in a separate storage location from the primary database to provide geographic and logical separation.

8.2 Point-in-Time Recovery

PostgreSQL write-ahead logging (WAL) is enabled, supporting point-in-time recovery (PITR). In the event of data corruption, accidental deletion, or an incident, we can restore the database to a specific point in time within the retention window to minimize data loss. Recovery procedures are documented and tested periodically.

8.3 Object Storage

Files stored in S3-compatible object storage benefit from the durability guarantees of the underlying storage provider. In production, AWS S3 is used, which provides 99.999999999% (11 nines) designed durability for stored objects through redundant storage across multiple facilities.

9. Incident Response

9.1 Monitoring and Alerting

The EcomIQX platform is monitored continuously for application errors, infrastructure health, and anomalous activity patterns. We use structured logging across application services to support investigation of security events. Alerting is configured for anomalous authentication patterns, service errors exceeding normal thresholds, and infrastructure health events.

9.2 Incident Response Procedures

We maintain documented incident response procedures covering detection, containment, eradication, and recovery phases. When a security incident is identified, our response follows these steps:

• Detection — alerts from monitoring systems, internal reports, or external disclosure trigger the response process
• Assessment — the incident is classified by severity based on data exposure risk, service impact, and scope of affected systems
• Containment — affected systems are isolated or patched to prevent further exposure
• Notification — affected customers are notified within the timeframe required by applicable law (GDPR: 72 hours to supervisory authority; customer notification as soon as practicable)
• Post-incident review — root cause analysis is conducted and controls are updated to prevent recurrence

9.3 Data Breach Notification

In the event of a confirmed data breach that affects your personal data or product catalog data, we will notify affected customers without undue delay. GDPR-regulated customers will be notified in accordance with Article 33 and 34 requirements. Notifications will describe the nature of the breach, the categories and approximate volume of data involved, likely consequences, and the measures we have taken or will take to address it.

10. Enterprise Security

Enterprise customers have access to additional security capabilities and contractual protections beyond those available on self-service plans.

10.1 Dedicated Instances

Enterprise clients can deploy EcomIQX as a dedicated self-hosted instance running on their own infrastructure. In a dedicated deployment, all data — including product catalog data, AI interaction logs, integration tokens, and user data — resides entirely within the customer's own environment. EcomIQX has no access to data in a self-hosted deployment except as explicitly agreed under a support arrangement. The customer organization acts as the sole data controller for all data in their instance.

10.2 Custom SSO

Enterprise deployments support integration with the customer's identity provider (IdP) via industry-standard SSO protocols, enabling centralized authentication management, enforcement of corporate password policies, and automatic deprovisioning when employees leave the organization. Contact [email protected] to discuss SSO configuration for your organization.

10.3 Network Isolation

Self-hosted enterprise deployments can be placed behind the customer's own network controls, including VPNs, private networking, IP allowlisting, and firewall rules. Because the instance runs on the customer's infrastructure, all network access policies are under the customer's direct control.

10.4 Audit Logs

Administrative actions are logged in a tamper-evident audit trail accessible to workspace owners and admins. Enterprise deployments include extended audit logging covering authentication events, role changes, integration connections and disconnections, and configuration updates. Audit logs provide a durable record of activity for security review and compliance purposes.

10.5 Data Processing Agreement

A Data Processing Agreement (DPA) formalizing EcomIQX's obligations as a data processor under GDPR Article 28 is available for enterprise customers. To request a DPA, contact [email protected].

11. Vulnerability Disclosure

11.1 Responsible Disclosure Policy

We welcome security researchers and customers who identify potential vulnerabilities in the EcomIQX platform. If you believe you have found a security issue, we ask that you:

• Report the issue to us privately before any public disclosure, giving us a reasonable opportunity to investigate and remediate
• Provide sufficient detail for us to reproduce and understand the issue (steps to reproduce, affected URLs or endpoints, potential impact)
• Avoid accessing, modifying, or deleting data that does not belong to you during your research
• Avoid disruptive testing such as denial-of-service attacks, automated scanning at high volume, or social engineering of EcomIQX staff

In return, we commit to acknowledging your report within 3 business days, keeping you informed of our investigation progress, and working to remediate confirmed vulnerabilities in a timeframe commensurate with their severity. We will not take legal action against researchers who act in good faith under this policy.

11.2 Security Contact

All security reports and inquiries should be sent to: [email protected]. For sensitive reports, you may request our PGP public key to encrypt your submission.

Please do not use general support channels for security disclosures, as those channels may be reviewed by a broader team before reaching our security staff.

12. Compliance

12.1 GDPR

EcomIQX is designed to support compliance with the General Data Protection Regulation (GDPR) for customers located in the European Economic Area, United Kingdom, and Switzerland. Our Privacy Policy documents our lawful bases for processing, data subject rights procedures, data retention practices, and international transfer mechanisms (Standard Contractual Clauses). Enterprise customers can request a Data Processing Agreement (DPA) formalizing processor obligations under GDPR Article 28.

12.2 CCPA / CPRA

We support the rights of California residents under the California Consumer Privacy Act (CCPA) and the California Privacy Rights Act (CPRA), including the rights to know, delete, correct, and opt out of sale. EcomIQX does not sell personal information. California-specific rights and how to exercise them are detailed in our Privacy Policy.

12.3 SOC 2 Type II

A SOC 2 Type II audit is in progress. We are actively building and documenting the controls required under the Trust Services Criteria (Security, Availability, Confidentiality). Enterprise customers who require a SOC 2 report as a prerequisite for procurement are encouraged to contact us at [email protected] to discuss current status and expected timeline.

12.4 PCI DSS

EcomIQX does not store, process, or transmit cardholder data. Payment processing is fully delegated to Stripe, a PCI DSS Level 1 service provider. Our integration with Stripe's tokenization approach removes us from the cardholder data environment for card number handling.

Contact

For security reports, vulnerability disclosures, DPA requests, or questions about our security practices:

• Security email: [email protected]
• General support: [email protected]

This page will be updated as our security controls, certifications, and compliance posture evolve. Material changes will be reflected in an updated effective date at the top of this page.