STIGQter STIGQter: STIG Summary: MongoDB Enterprise Advanced 7.x Security Technical Implementation Guide Version: 1 Release: 2 Benchmark Date: 01 Jul 2026:

When invalid inputs are received, MongoDB must behave in a predictable and documented manner that reflects organizational and system objectives.

DISA Rule

SV-265950r1028819_rule

Vulnerability Number

V-265950

Group Title

SRG-APP-000447-DB-000393

Rule Version

MD7X-00-009000

Severity

CAT II

CCI(s)

Weight

10

Fix Recommendation

Document validation can be added at the time of creation of a new collection.

Also, existing collections can be modified with document validation rules.

Use the "validator" option to create or update a collection with the desired validation rules.

Refer to Schema Validation documentation for details:

https://www.mongodb.com/docs/v7.0/core/schema-validation/

Check Contents

When an application requires specific fields to be validated at the collection level, MongoDB's schema validation ensures that there are no unintended schema changes or improper data types for those fields.

Refer to the application's guidelines and documentation. If there is no requirement for collection-level schema validation for specific fields, this is not a finding.

If the application's guidelines and documentation require collection-level schema validation for a specific collection on specific fields, follow these steps:

1. As a user with the "dbAdminAnyDatabase" role, run the following commands for each database that contains collections used by the application:

use <database>
db.getCollectionInfos()

This returns an array of documents containing information about all collections within "<database>".

2. For each specific collection (identified by the "name:" field in the output) used by the application that requires a schema validation, check the "options" sub-document for that collection.

3. If the "options" sub-document for that specific collection does not contain a "validator" sub-document, this is a finding.

Below shows an example output of a collection named "testCollectionWithValidator" (indicated by "name" field) with a "validator" in the "options" sub-document:
[
{
name: 'testCollectionWithValidator',
type: 'collection',
options: {
validator: {
'$jsonSchema': {
bsonType: 'object',
required: [ 'username', 'password' ],
properties: {
username: {
bsonType: 'string',
minLength: 3,
description: 'must be a string and is required with a minimum length of 3 characters'
},
password: {
bsonType: 'string',
minLength: 8,
description: 'must be a string and is required with a minimum length of 8 characters'
}
}
}
},
validationLevel: 'strict',
validationAction: 'error'
},
info: {
readOnly: false,
uuid: UUID('cf0629c2-7355-4bf8-a44b-54b9f31e4845')
},
idIndex: { v: 2, key: { _id: 1 }, name: '_id_' }
}
]

If the "options" sub-document contains a "validator", verify it against the application guidelines and documentation. Ensure the validator checks for the presence of all fields specified in the application guidelines and documentation needing a collection level validation and confirm that the correct data types and/or ranges are being validated.

If any fields specified in the application guidelines or documentation are missing from the validator, or if present and the fields do not have the correct data types and/or ranges, this is a finding.

Vulnerability Number

V-265950

Documentable

False

Rule Version

MD7X-00-009000

Severity Override Guidance

When an application requires specific fields to be validated at the collection level, MongoDB's schema validation ensures that there are no unintended schema changes or improper data types for those fields.

Refer to the application's guidelines and documentation. If there is no requirement for collection-level schema validation for specific fields, this is not a finding.

If the application's guidelines and documentation require collection-level schema validation for a specific collection on specific fields, follow these steps:

1. As a user with the "dbAdminAnyDatabase" role, run the following commands for each database that contains collections used by the application:

use <database>
db.getCollectionInfos()

This returns an array of documents containing information about all collections within "<database>".

2. For each specific collection (identified by the "name:" field in the output) used by the application that requires a schema validation, check the "options" sub-document for that collection.

3. If the "options" sub-document for that specific collection does not contain a "validator" sub-document, this is a finding.

Below shows an example output of a collection named "testCollectionWithValidator" (indicated by "name" field) with a "validator" in the "options" sub-document:
[
{
name: 'testCollectionWithValidator',
type: 'collection',
options: {
validator: {
'$jsonSchema': {
bsonType: 'object',
required: [ 'username', 'password' ],
properties: {
username: {
bsonType: 'string',
minLength: 3,
description: 'must be a string and is required with a minimum length of 3 characters'
},
password: {
bsonType: 'string',
minLength: 8,
description: 'must be a string and is required with a minimum length of 8 characters'
}
}
}
},
validationLevel: 'strict',
validationAction: 'error'
},
info: {
readOnly: false,
uuid: UUID('cf0629c2-7355-4bf8-a44b-54b9f31e4845')
},
idIndex: { v: 2, key: { _id: 1 }, name: '_id_' }
}
]

If the "options" sub-document contains a "validator", verify it against the application guidelines and documentation. Ensure the validator checks for the presence of all fields specified in the application guidelines and documentation needing a collection level validation and confirm that the correct data types and/or ranges are being validated.

If any fields specified in the application guidelines or documentation are missing from the validator, or if present and the fields do not have the correct data types and/or ranges, this is a finding.

Check Content Reference

M

Target Key

5637