Limitations

beta

Client-Side Field Level Encryption is available as a beta. The contentsof this page may change during the beta period.

Read and Write Operation Support

The mongod only stores encrypted BinData and applies any aggregation expression or query operatorspecifying an encrypted field against the BinData value. While theexpression or operator may support BinData fields, the resultingvalue may be incorrect or unexpected when compared to issuing that sameexpression or operator against the decrypted value. The mongodthrows an error if the expression or operator does not supportBinData values.

For example, consider a deterministically encrypted integer Salary.A query filters for documents where Salary is greater than100000. The application explicitly (manually) encrypts the queryvalue using deterministic encryption prior to issuing the query. Themongod compares the encrypted BinData value of 100000 tothe encrypted BinData values stored in each document. While theoperation returns successfully, the comparison of the BinData valuesmay return a different result than the comparison of the decryptedinteger values.

Automatic client-side field level encryption rejects read or writeoperations which would return incorrect or unexpected results whenissued against an encrypted field. For complete documentation, seeRead/Write Support with Automatic Field Level Encryption.Applications performing explicit (manual) encryption may reference thelinked page as guidance for issuing read/write operations againstencrypted fields.

Views

Queries against views on collectionscontaining client-side field level encrypted values may returnunexpected or incorrect results if either the underlying viewaggregation pipeline or the query references encrypted fields. Ifcreating a view on a collection containing client-side field levelencrypted values, avoid operating on encrypted fields to mitigate therisk of unexpected or incorrect results.

While 4.2-compatible drivers configured for automatic client-side fieldlevel encryption have validation forunsupported read and write operations, the underlying support librarycannot introspect the view catalog to identify a given collection as aview. Applications therefore cannot rely on the automatic field levelencryption validation to prevent unsupported queries against views oncollections with encrypted fields.

For applications using explicit (manual) encryption to query a view on acollection containing encrypted values, consider constructing the queryusing only query operators with known normal behavior when issued against encrypted fields.

Collation

Client-side field level encryption does not respect user-specifiedcollations or collection default collations. Field level encryption obscures the field valueand prevents normal collation behavior. Collation-sensitive queriesagainst encrypted fields may return unexpected or incorrect results.

While 4.2-compatible drivers configured for automatic client-side fieldlevel encryption have validation forunsupported read and write operations, the underlying support librarycannot introspect the collection catalog to identify the defaultcollation. Applications therefore cannot rely on the automatic fieldlevel encryption validation to prevent querying on encrypted fields withcollation defaults.

Unique Indexes

Unique indexescannot guaranteeuniqueness if the index key specifies any randomly encrypted fields.

Fields encrypted using the randomalgorithm always produce a different encrypted value given a specificinput. The server considers each encrypted value unique even though thedecrypted value itself is not unique. The collection can thereforecontain multiple documents with duplicate decrypted values for a fieldwith an index-enforced unique constraint.

While 4.2-compatible drivers configured for automatic client-side fieldlevel encryption have validation forunsupported read and write operations, the underlying support librarycannot introspect the index catalog to identify a given field as unique.Applications therefore cannot rely on the automatic field levelencryption validation to prevent unique constraint violations onrandomly-encrypted fields.

Shard Key

Specifying a shard key on encrypted fields _or_encrypting fields of an existing shard key may result in unexpected orincorrect sharding behavior.

While 4.2-compatible drivers configured for automatic client-side fieldlevel encryption have validation forunsupported read and write operations, the underlying support librarycannot introspect the sharding catalog metadata to identify shard keyfields. Applications therefore cannot rely on the automatic field levelencryption validation to prevent encryption of shard key fields.

Read/Write Query Support

Automatic client-side field level encryption supports a subset ofcommands, query operators, update operators, aggregation stages, andaggregation expressions. For complete documentation, seeRead/Write Support with Automatic Field Level Encryption.