Client-Side Encryption and Data Privacy

Key Control Areas

• Cryptographic Key Lifecycle (SC-12, SC-12(1), SC-13, SC-17): The entire security of client-side encryption rests on the key lifecycle. SC-12 governs key generation: keys must be generated using the Web Crypto API's `generateKey()` with approved algorithms (AES-256-GCM) and the browser's cryptographically secure random number generator -- never from Math.random() or user-derived values without proper key derivation. Key storage in localStorage is acceptable for single-device scenarios but must be documented as a risk: any JavaScript running in the same origin can read localStorage, making XSS the primary threat vector. SC-12(1) addresses key availability: the application must provide key export (JWK download) and key import (JWK upload with validation) to prevent data loss when browsers are cleared or devices are replaced. The export format must include algorithm metadata (`kty: oct`, `alg: A256GCM`) enabling validation on import. SC-13 mandates approved cryptographic algorithms: AES-256-GCM provides authenticated encryption (confidentiality + integrity + authenticity) in a single operation, which is critical because unauthenticated encryption (AES-CBC without HMAC) allows ciphertext manipulation. The 96-bit IV must be generated fresh for every encryption operation using `crypto.getRandomValues()`. SC-17 applies when key wrapping is used for multi-device access: the wrapped key stored server-side should use a key derived from the user's passphrase via an approved KDF (PBKDF2 with >=600,000 iterations or Argon2id), and the wrapping scheme should use AES-KW or AES-GCM.
• Data Flow Separation and Access Enforcement (AC-03, AC-04, AC-21, SC-08, SC-28): The dual-path architecture requires rigorous enforcement of which data flows are encrypted and which are plaintext. AC-03 enforces access rules at the API layer: endpoints that accept encrypted data must store the ciphertext verbatim without parsing; endpoints that accept aggregate plaintext must validate that no personally identifiable information is included. AC-04 controls information flow between the two paths: the client is the enforcement boundary, and the application must never allow encrypted private data to flow into the plaintext aggregate path (or vice versa) without explicit user action. AC-21 governs information sharing decisions: when users choose to contribute data to an aggregate pool (e.g., anonymous benchmarks), the application must clearly explain what is shared, obtain explicit consent, and transmit only the minimum required data in plaintext -- never the encrypted payload. SC-08 protects both paths in transit with TLS, though for the encrypted path, TLS is defence-in-depth since the payload is already encrypted. SC-28 addresses protection at rest: the server stores ciphertext that it cannot decrypt, which is the strongest form of rest protection. However, the server must still protect the ciphertext from deletion, corruption, and unauthorised modification -- integrity even without confidentiality access. Database backups inherit the same protection: they contain ciphertext that is useless without the client-side key.
• Privacy Engineering and Data Minimisation (PT-02, PT-03, PT-04, PM-25, SA-08): Client-side encryption is a privacy engineering pattern that must be situated within the organisation's broader privacy programme. PT-02 establishes the authority to process PII: with client-side encryption, the server processes encrypted PII that it cannot read, but it still processes metadata (timestamps, IP addresses, payload sizes, access frequency) that may constitute personal data under GDPR. PT-03 defines processing purposes: encrypted assessment data is processed solely for user self-service; plaintext benchmark data is processed for anonymous aggregation. These purposes must be documented and enforced. PT-04 governs consent: users must provide informed consent before any plaintext data leaves the client, with clear explanation of what the server can and cannot see. The privacy notice must distinguish between encrypted data (server stores but cannot read) and metadata (server can observe). PM-25 mandates PII minimisation: the aggregate data path must strip all identifying information before transmission -- only numeric scores, never names, notes, or organisational identifiers. SA-08 applies privacy by design principles: client-side encryption should be the default for all sensitive data (not opt-in), the key should be generated transparently, and the encryption should be invisible to the user experience while being documented for transparency.
• Legacy Migration and Version Management (CM-03, CM-06, SA-10, SI-07): Introducing client-side encryption to an existing application with plaintext data requires careful migration. CM-03 governs change control: the migration from plaintext to encrypted storage is a high-impact change that must preserve backward compatibility. The versioned ciphertext format (`enc:v1:` prefix) enables the application to distinguish encrypted from legacy plaintext data and handle both correctly -- old data works as before and gets encrypted on next save. CM-06 defines configuration for the encryption scheme: algorithm (AES-256-GCM), IV length (96 bits), key size (256 bits), encoding (base64), and format version. These must be consistent across all clients and documented for interoperability. SA-10 requires configuration management of the client-side cryptographic code: the encryption/decryption module must be versioned, tested, and reviewed with the same rigour as server-side security code, despite running in the browser. SI-07 verifies the integrity of the cryptographic code delivered to the browser: if an attacker can modify the JavaScript (via compromised CDN, XSS, or supply chain attack), they can exfiltrate keys or bypass encryption entirely. Subresource Integrity (SRI) hashes, Content Security Policy (CSP), and minimising third-party script dependencies are essential mitigations.
• Audit, Compliance, and Incident Response (AU-02, AU-03, AU-06, IR-04, IR-06): Client-side encryption creates a unique audit and compliance posture. AU-02 defines auditable events: key generation (timestamp, algorithm, browser fingerprint), encryption operations (count, not content), key export events, key import events, decryption failures (potential indicator of key mismatch or data corruption), and plaintext data sharing events (benchmark contributions). Note that the server cannot log the content of encrypted data by design. AU-03 specifies record content: audit records must include the operation type, timestamp, data version (enc:v1), payload size, and user identifier -- but never the plaintext content or the encryption key. AU-06 analyses encryption-specific anomalies: repeated decryption failures may indicate key corruption or a tampered ciphertext; a sudden switch from encrypted to plaintext payloads may indicate a bypassed client; unusually large payloads may indicate data exfiltration attempts. IR-04 addresses incident response: a server breach is significantly less impactful because the attacker obtains only ciphertext, but the incident response plan must still address metadata exposure, potential ciphertext manipulation, and the possibility that the attacker modified the JavaScript to capture future keys. IR-06 requires disclosure: even though encrypted data is unreadable, regulators may still require breach notification for the metadata exposure, depending on jurisdiction.
• Browser Security and Client Integrity (SC-07, SI-07, SC-23, AT-02): The browser is the trust boundary, and its integrity determines the encryption's effectiveness. SC-07 defines the boundary: the application's origin (scheme + host + port) is the security perimeter within which the encryption key is accessible. Any JavaScript executing within this origin -- including injected scripts from XSS, compromised dependencies, or browser extensions -- can access localStorage and therefore the encryption key. SI-07 protects the integrity of the cryptographic code: Content Security Policy headers must restrict script sources to the application's own origin and trusted CDNs with SRI hashes; inline scripts must be eliminated or nonced; eval() must be forbidden. Third-party analytics, advertising, and chat widgets are particularly dangerous because they execute arbitrary code within the application's origin. SC-23 ensures session authenticity: the encryption key is scoped to the browser session via localStorage, and the application must never transmit the key to the server (not in headers, not in request bodies, not in error reports). AT-02 covers user awareness: users must understand that their encryption key is stored locally, that clearing browser data deletes it, that export is their responsibility, and that the service cannot recover their data. This is a fundamental shift from the 'forgot password' mental model and must be communicated clearly and repeatedly.

When to Use

This pattern is indicated for any application that handles sensitive user data where the service operator should not -- or does not need to -- read the data. Specific indicators include: applications storing personal health information (patient journals, symptom trackers), financial data (personal budgets, portfolio analysis), security assessments (maturity scores, vulnerability data), personal notes and diaries, survey responses containing opinions or whistleblower reports, legal case notes, and any application where a data breach should not expose user content. It is particularly valuable for small teams and startups that cannot afford dedicated security operations: by making the data unreadable on the server, you eliminate the most damaging breach scenario even if your server security is imperfect. The pattern is also indicated when regulatory compliance (GDPR Article 25, HIPAA, DORA) requires demonstrable data protection by design, and when users or their organisations (CISOs, DPOs) require assurance that the service cannot access their data.

When NOT to Use

Applications requiring server-side search, sorting, or filtering of encrypted data cannot use this pattern without additional cryptographic techniques (searchable encryption, order-preserving encryption) that significantly increase complexity and may weaken the security model. Real-time collaborative applications where multiple users need simultaneous access to the same encrypted data require a shared key distribution mechanism (e.g., group key management, key escrow via a trusted server component) that partially undermines the 'server cannot read data' guarantee. Applications where the service must perform computations on user data (recommendation engines, ML model training on user content, server-generated reports) need the data in plaintext on the server and should use traditional server-side encryption at rest instead. Applications targeting users who cannot manage a key file (elderly users, children, users with cognitive disabilities) may find the key loss risk unacceptable -- though passphrase-based key wrapping can mitigate this. If the threat model includes a compromised browser or malicious browser extensions, client-side encryption provides no protection because the attacker has access to the key and plaintext before encryption.

Typical Challenges

The dominant challenge is key management UX. Users accustomed to 'forgot password' flows do not expect that losing their browser data means permanent data loss. The application must make key backup prominent, explain it clearly, and accept that some users will still lose their keys. Multi-device access is the second challenge: without key wrapping via a passphrase (which adds complexity and a shared secret), users must manually export and import their key file on each device. This is acceptable for low-frequency-of-change applications (assessments, configurations) but impractical for real-time collaborative tools. Server-side operations on encrypted data are impossible: you cannot search, sort, filter, or compute aggregates on ciphertext without additional cryptographic techniques (searchable encryption, homomorphic encryption) that add significant complexity and performance overhead. The current pattern uses the clean separation approach instead: anything the server needs to compute on is kept in plaintext (with user consent) or computed client-side. XSS remains the critical vulnerability: because the encryption key is in localStorage accessible to any script in the origin, a single XSS vulnerability defeats the entire encryption scheme. This makes CSP, SRI, and minimal third-party dependencies essential -- not optional. Performance is generally not a concern: AES-256-GCM via Web Crypto API processes megabytes per second even on mobile devices; the encryption/decryption overhead is invisible compared to network latency.

Threat Resistance

Client-Side Encryption provides strong protection against the most common and damaging data breach scenarios. Server-side data breach is neutralised for encrypted content: attackers who compromise the database, backups, or server infrastructure obtain only ciphertext that is computationally infeasible to decrypt without the user's key (SC-12, SC-13, SC-28). Rogue insider access is eliminated: database administrators, support engineers, and system operators cannot read encrypted user data even with full database access (AC-03, AC-04). Lawful interception and compelled disclosure is limited: the service operator genuinely cannot produce plaintext in response to a subpoena or government request for encrypted data -- they can only produce the ciphertext (note: this may create legal complications in some jurisdictions). Man-in-the-middle attacks on the encrypted payload are defeated: even if TLS were compromised, the AES-GCM authenticated ciphertext cannot be read or tampered with without the key (SC-08, SC-13). Cloud provider access is prevented: the hosting provider (Cloudflare, AWS, Azure) stores only ciphertext and cannot access user content (SC-28). The primary residual risks are: XSS attacks that exfiltrate the key from localStorage (mitigated by CSP and SRI per SI-07); compromised JavaScript delivery that replaces the encryption code (mitigated by SRI and supply chain security per SA-10); and metadata exposure (timestamps, payload sizes, access patterns) that may reveal information about the user even without decrypting the content (mitigated by minimisation per PM-25).

Assumptions

The target application runs in modern browsers that support the Web Crypto API (all major browsers since 2015: Chrome 37+, Firefox 34+, Safari 11+, Edge 12+). The data being encrypted is structured (JSON, form data) and can be serialised to a string before encryption. The server can store and return opaque string values without parsing them. Users have a single primary device or are willing to manually transfer their encryption key to additional devices. The application does not require server-side search or computation on encrypted data (if it does, techniques like homomorphic encryption or secure enclaves are needed -- see Contra-indications). The application's origin is protected by HTTPS and a strong Content Security Policy.

Developing Areas

• Key management UX for non-technical users remains the fundamental barrier to client-side encryption adoption. Despite decades of research into usable security, no approach has reconciled the tension between user convenience and cryptographic key responsibility. Key wrapping via passphrases introduces shared secret risk; platform-managed key sync (iCloud Keychain model) shifts trust to the platform vendor; and manual key export requires user discipline that studies consistently show fewer than 20% of users maintain.
• Regulatory acceptance of client-side encryption varies dramatically across jurisdictions and is becoming more contentious. The tension between lawful access requirements (government demand to access encrypted data) and privacy engineering (building systems where the operator cannot access data) is unresolved. The EU, UK, and Australia have each proposed or enacted legislation that could mandate backdoor access, while GDPR Article 25 simultaneously encourages encryption as data protection by design. Organisations deploying CSE must monitor this evolving legal landscape and prepare for scenarios where their architecture conflicts with future legislation.
• Key recovery mechanisms that preserve security guarantees while preventing permanent data loss are an active research area with no production-ready solutions. Social recovery (Shamir secret sharing among trusted contacts), threshold key management, and hardware-backed escrow each solve part of the problem but introduce new trust assumptions. The cryptocurrency wallet recovery ecosystem has explored these approaches extensively, but translating that experience to enterprise data encryption contexts -- where regulatory compliance and audit requirements add constraints -- remains an open challenge.
• Web Crypto API maturity has reached a stable baseline for symmetric encryption (AES-GCM) but gaps remain for advanced use cases. Key agreement protocols, post-quantum algorithms, and streaming encryption are either unsupported or inconsistently implemented across browsers. The lack of a standard secure storage mechanism (beyond localStorage, which is vulnerable to XSS) means that IndexedDB, service workers, and the upcoming File System Access API are being pressed into service as key stores without established security guarantees.
• Client-side encryption for collaborative applications -- where multiple users need concurrent access to shared encrypted data -- is a developing frontier. End-to-end encrypted collaboration (as in Matrix/Element, Tresorit, or Proton Drive) requires group key management, key rotation on membership changes, and conflict resolution for concurrent edits, all without server-side access to plaintext. Current approaches work for messaging and file storage but have not scaled to real-time collaborative editing with acceptable latency and complexity.