Spring Data MongoDB的Criteria是否防注入？动态查询防NoSQL注入方法

Great question—NoSQL injection is a critical concern when building dynamic APIs that query MongoDB, so let’s walk through both the safety of Spring Data MongoDB’s Criteria and how to harden your code.

Is Spring Data MongoDB's Criteria API Injection-Safe? #

Short answer: Yes, by default, the Criteria API is designed to prevent NoSQL injection—but only if you use it correctly.

Here’s why: The Criteria API builds queries using a type-safe object model, not raw string concatenation. When you call Criteria.where(dbFieldName).is(name), the is() method treats the name parameter as a literal value, not a MongoDB query operator (like $gt, $in, or $where). Spring Data MongoDB converts this into a properly structured BSON document under the hood, so user input can’t be interpreted as executable query logic unless you explicitly allow it.

That said, there are edge cases where risks can creep in—mostly around user-controlled field names or improper handling of regex/operator logic.

How to Secure Your Specific Code #

Your code snippet:

Criteria nameCriteria = Criteria.where(dbFieldName).is(name);
dynamicQuery.addCriteria(nameCriteria);

To lock this down, follow these key steps:

1. Enforce a Field Name Whitelist #

The biggest risk here is if dbFieldName comes directly from user input. Attackers could try to pass MongoDB operators (like $where or $expr) as field names to craft malicious queries.

Fix this by defining a list of allowed fields that correspond to your MongoDB collection’s schema, and reject any dbFieldName that isn’t in this list:

// Define your allowed fields (match your collection's schema)
Set<String> ALLOWED_FIELDS = Set.of("username", "email", "userId");

if (!ALLOWED_FIELDS.contains(dbFieldName)) {
    throw new IllegalArgumentException("Invalid field name: " + dbFieldName);
}

This ensures you only query fields you explicitly approve.

2. Treat User Input as Literal Values #

While is() is safe for exact matches, if you ever expand to regex queries (e.g., partial string searches), avoid passing raw user input directly to regex(). Instead, use Pattern.LITERAL to ensure special regex characters (like ., *, or +) are treated as plain text:

// Safe regex search (no injection risk)
Criteria regexCriteria = Criteria.where("username")
    .regex(Pattern.compile(name, Pattern.LITERAL));

3. Never Let Users Control Query Operators #

If you need to support advanced queries (like "greater than" or "contains"), don’t let users pass operators (e.g., gt, in) directly into your API. Instead, map user-friendly parameters to the appropriate Criteria methods:

// Example: User passes "operator=gt" and "value=100"
String userOperator = request.getParameter("operator");
Integer userValue = Integer.parseInt(request.getParameter("value"));

Criteria criteria = Criteria.where("age");
switch(userOperator) {
    case "gt":
        criteria.gt(userValue);
        break;
    case "lt":
        criteria.lt(userValue);
        break;
    // Only support operators you explicitly define
    default:
        throw new IllegalArgumentException("Unsupported operator");
}

4. Limit Query Scope and Permissions #

Even if an attacker slips through, minimize damage by:

• Restricting returned fields to only what’s necessary (use Query.fields().include(ALLOWED_FIELDS)).
• Ensuring the API’s service account has minimal permissions in MongoDB (e.g., no write access, only read access to specific collections).

Final Takeaway #

The Criteria API itself provides solid protection against NoSQL injection by avoiding raw query string construction. The real work is in validating user-controlled inputs (especially field names) and avoiding unsafe patterns like letting users define query operators or raw regex. Stick to these practices, and your API will be well-protected.

内容的提问来源于stack exchange，提问作者alegria