Client Side Field Level Encryption (CSFLE)
Parent: Client Side Operations Timeout (CSOT) · Published reference · snapshot 2026-10-24 · viability 3.10 / 5 (skip)
↓ Facts as markdownall context files
Source-anchored research for Client Side Field Level Encryption (CSFLE). Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- Mongoose generates the CSFLE schemaMap from encrypted models registered before the connection opens. If models are registered after connecting, the application must supply schemaMap itself. Registering models before connect() or openUri() is therefore part of encryption configuration. (high confidence) (verified as of 2026-10-21) [source]
How it works
- Low-cardinality fields encrypted deterministically are susceptible to frequency-analysis recovery. Randomized encryption improves protection against that attack when the application does not need to query that field. (low confidence) [source]
How-to and procedures
- To verify stored encryption, inspect the document through a client without automatic decryption. A read through an encryption-enabled client can show plaintext because the driver decrypts results automatically. (high confidence) [source]
Problems, failure modes and limitations
- Deterministic CSFLE maps repeated plaintext to repeated ciphertext under the same encryption configuration and supports equality queries. Randomized CSFLE produces different ciphertext and cannot evaluate predicates directly against that encrypted field. (high confidence) [source]
- Randomized CSFLE changes the ciphertext between encryptions and prevents direct predicates on the encrypted field. It can encrypt an entire object or array, but the server cannot query its nested plaintext fields. Entire objects and arrays cannot use deterministic CSFLE. (low confidence) [source]
Comparisons and alternatives
- The GCP automatic-CSFLE tutorial uses crypt_shared, the Automatic Encryption Shared Library, as the preferred alternative to mongocryptd. Unlike mongocryptd, it does not require spawning a separate process. (low confidence) [source]
Facts and statements
- CSFLE encrypts selected document fields in the application before they reach MongoDB and decrypts them on the client. The database stores ciphertext for those fields; applications authorized to decrypt still handle plaintext. (high confidence) [source]
- Automatic CSFLE uses encryption metadata in a JSON schema to encrypt writes and decrypt reads through the driver. Explicit CSFLE requires application code to select and encrypt values and query operands; decryption can be explicit or automatic. (high confidence) [source]
- For Atlas applications using GCP KMS, the CSFLE tutorial creates a symmetric customer master key in Google Cloud KMS, then creates a data encryption key encrypted with that key. The application configures the gcp KMS provider and a MongoDB key-vault collection. (high confidence) [source]
- Keep automatic-encryption rules in a trusted client-side schemaMap. Without a local entry, the client downloads the server schema; a compromised server can remove encryption markings and induce the client to transmit plaintext. Server-side validation can enforce required encrypted fields but does not authenticate that downloaded schema. (high confidence) [source]
- CSFLE does not guarantee protection against an adversary with the encryption keys, or against an adversary with arbitrary write access to encrypted collections. Its protection boundary must not be described as protection from every database or application compromise. (low confidence) [source]
- CSFLE permits different encryption keys for the same field across records, including per-tenant keys. Both MongoDB's selection guidance and Spring Data's integration documentation identify this use case. (high confidence) [source]
- MongoDB documents explicit encryption and automatic decryption for Community Server, Enterprise Advanced, and Atlas; automatic encryption requires Enterprise or Atlas. For Community automatic decryption, configure bypassAutoEncryption=true with the key vault and KMS provider. (low confidence) (verified as of 2026-10-14) [source]
- Automatic CSFLE uses encryption rules in a JSON schema supplied to the MongoDB driver, together with a key-vault namespace and KMS-provider configuration, to avoid explicit encryption calls in normal application reads and writes. (high confidence) [source]
- The GCP tutorial supports attached-service-account authentication by supplying an empty gcp provider map; it also documents service-account email/private-key credentials and access-token alternatives. Confirm credential support in the chosen driver before deployment. (low confidence) (verified as of 2026-10-14) [source]
- Deterministic CSFLE produces the same ciphertext for a given value and key and supports equality-style queries through a configured client. Repeated ciphertext exposes value frequencies, making low-cardinality data susceptible to frequency analysis. (low confidence) [source]
- Spring Data configures automatic CSFLE by supplying a MongoJsonSchema through AutoEncryptionSettings.schemaMap; its explicit CSFLE support uses the driver encryption library and @ExplicitEncrypted property conversion. Annotated collections, maps, and objects are encrypted as whole values. (low confidence) (verified as of 2026-10-23) [source]
Children
- No children recorded.