Version 1.0 · Last updated: 14 July 2026 · Effective: 14 July 2026

Technical Safeguards

• K-Anonymity Password Checks: When you run a password security check, we apply the k-anonymity model. Your password is hashed client-side using SHA-1, and only the first 5 characters of the hash (out of 40) are sent to our servers. We return all breach entries matching that prefix — your client then determines locally whether your full hash appears. Your actual password, its complete hash, or any derivative that could identify it never leaves your device or touches our infrastructure.
• Encryption at Rest: Sensitive stored fields are encrypted at the application layer using AES-256-GCM with a per-record IV before being written to the database, making ciphertext unreadable even with direct database access. All other personal data (email, session metadata) relies on infrastructure-level encryption provided by the database host. Admin accounts use passwordless magic-link authentication — no admin passwords exist to be hashed or stolen.
• Encryption in Transit: All communications between your browser and our servers are protected by TLS 1.3 — the current gold standard in transport-layer security. Older protocol versions (TLS 1.0, 1.1) and weak cipher suites are explicitly disabled. We enforce HTTP Strict Transport Security (HSTS) with a 12-month max-age and include our domain in browser preload lists, eliminating the possibility of downgrade attacks.
• Zero-Log Password Processing: Password check queries are processed in memory only. We explicitly configure our application layer and infrastructure to suppress request body logging for all password-related endpoints. No query parameter, request body, or server log will ever contain a submitted password or its hash. Application logs capture only anonymised metadata (timestamp, response code, request duration).
• Secure Cookie Architecture: Authentication sessions are stored in HttpOnly, Secure, SameSite=Lax cookies. HttpOnly prevents JavaScript access, eliminating XSS-based session theft. SameSite=Lax blocks all cross-site non-GET requests (POST, PATCH, DELETE), preventing CSRF attacks, while correctly allowing the session cookie to be received when a user follows a magic-link from their email client. An explicit CSRF-token check (HMAC-SHA256 of the session JWT) provides additional defence-in-depth for all state-changing requests. In production, we use __Host- prefixed cookies, which bind the session to the exact origin and cannot be set by subdomains.
• Row-Level Security (RLS): Our database enforces Row-Level Security policies at the PostgreSQL engine level. Each database query is automatically scoped to the authenticated user's data — even if application code contains a bug that fails to filter by user ID, the database engine itself prevents cross-user data access. Administrative operations use a separate, privilege-separated database role that bypasses RLS only for explicitly authorised queries.

Organisational Safeguards

• Principle of Least Privilege: Every team member and system component has access only to the minimum data necessary for their role. Database credentials are role-separated; administrative accounts are distinct from service accounts. Access permissions are reviewed quarterly.
• Security-First Development Lifecycle: All code changes undergo security review before deployment. We conduct threat modelling for new features that process personal data, and we follow OWASP Top 10 guidelines as a baseline minimum for web application security.
• Incident Response Plan: We maintain a documented incident response playbook covering detection, containment, eradication, recovery, and post-incident review. Personal data breaches trigger our GDPR notification procedure within 72 hours of detection.
• Vendor & Sub-Processor Due Diligence: All third-party sub-processors are assessed for security posture and GDPR compliance before onboarding. Data Processing Agreements (DPAs) are in place with every sub-processor handling personal data.
• No Data Brokers, Ever: We will never sell, rent, or share your personal data with data brokers, advertising networks, or any third party for commercial gain. This is a founding commitment of our platform.

Found a Vulnerability?

We operate a responsible disclosure policy. If you discover a security vulnerability in our platform, please report it privately at security@clearex.market before public disclosure so we can address it promptly and protect our users.

We aim to acknowledge reports within 48 hours and provide a resolution timeline within 7 days.

Contact

For security enquiries: security@clearex.market For data protection concerns: privacy@clearex.market