NoSQL Injection: The Attack Nobody Talks About (but That Hits Hard)

"I know SQL Injection, I'm safe!" - said the company running MongoDB in production.

Spoiler: they weren't.

The Crime Scene

Hypothetical scenario: it's Monday morning, the coffee is still hot, and a client calls you in a panic.

Client: "Our e-commerce has been breached!"
Us: "SQL Injection?"
Client: "But we use MongoDB!"
Us: "Ah... NoSQL Injection then."
Client: "No... what?"

And here we are, explaining that yes, NoSQL databases can be "injected" too. And no, it's not sci-fi.

Warning: 95% of developers know what SQL Injection is. Only 30% have ever heard of NoSQL Injection. Guess what percentage of modern apps use MongoDB?

NoSQL Injection: The Bad Cousin No One Tells You About

SQL Injection vs NoSQL Injection

Aspect	SQL Injection	NoSQL Injection
Fame	Brad Pitt of security	Who?
Documentation	Tons	"Search on StackOverflow"
Awareness	High	"But MongoDB is secure by default!"
Impact	Devastating	Equally devastating
Difficulty to defend	Medium	Low (if you know what to do)

How Does a NoSQL Injection Work?

Let's take a practical example. If a client asked us tomorrow to review this "harmless" API:

// The "innocent" login endpoint
app.post('/login', async (req, res) => {
    const { username, password } = req.body;
    
    // What could possibly go wrong?
    const user = await db.collection('users').findOne({
        username: username,
        password: password
    });
    
    if (user) {
        res.json({ success: true, token: generateToken(user) });
    }
});

An attacker could send:

{
    "username": "admin",
    "password": { "$ne": null }
}

Translation: "Give me the admin user with password not equal to null" (so... any admin).

Result: Access granted. 🎉 (for the attacker)

The Defense Plan We'd Propose

If this hypothetical client asked us "How do we protect ourselves?", here's what we'd do:

1. Input Sanitization - The Basics

// BEFORE: Trust issues? Never heard of them
const user = await db.collection('users').findOne({
    username: req.body.username,
    password: req.body.password
});

// AFTER: Trust no one, not even yourself
const sanitize = require('mongo-sanitize');

const cleanUsername = sanitize(req.body.username);
const cleanPassword = sanitize(req.body.password);

// Additional type checking
if (typeof cleanUsername !== 'string' || typeof cleanPassword !== 'string') {
    return res.status(400).json({ error: 'Invalid input type' });
}

const user = await db.collection('users').findOne({
    username: cleanUsername,
    password: hashPassword(cleanPassword) // Never store plain passwords!
});

2. Schema Validation - MongoDB Is Not Anarchy

Note: "But MongoDB is schemaless!" - Sure, but that's like leaving your house with no doors if you leave everything open.

// Define a proper schema validation
db.createCollection('users', {
    validator: {
        $jsonSchema: {
            bsonType: 'object',
            required: ['username', 'password', 'email'],
            properties: {
                username: {
                    bsonType: 'string',
                    pattern: '^[a-zA-Z0-9_]{3,30}$',
                    description: 'Username must be alphanumeric'
                },
                password: {
                    bsonType: 'string',
                    description: 'Hashed password'
                },
                email: {
                    bsonType: 'string',
                    pattern: '^[a-z0-9._%+-]+@[a-z0-9.-]+\\.[a-z]{2,}$'
                }
            }
        }
    }
});

3. Query Parameterization - The Holy Grail

// Create safe query builders
class SafeQueryBuilder {
    constructor(collection) {
        this.collection = collection;
    }
    
    async findUser(username, password) {
        // Validate types first
        if (typeof username !== 'string' || typeof password !== 'string') {
            throw new Error('Invalid parameter types');
        }
        
        // Use exact match operators only
        return await this.collection.findOne({
            $and: [
                { username: { $eq: username } },
                { password: { $eq: hashPassword(password) } }
            ]
        });
    }
}

// Usage
const safeQuery = new SafeQueryBuilder(db.collection('users'));
const user = await safeQuery.findUser(username, password);

4. Rate Limiting & Monitoring - The Guardian Angel

// Implement rate limiting and suspicious activity detection
const rateLimit = require('express-rate-limit');
const MongoSanitize = require('express-mongo-sanitize');

// Rate limiter configuration
const loginLimiter = rateLimit({
    windowMs: 15 * 60 * 1000, // 15 minutes
    max: 5, // 5 attempts
    message: 'Too many login attempts',
    handler: (req, res) => {
        // Log suspicious activity
        logger.warn({
            ip: req.ip,
            attempted_username: req.body.username,
            timestamp: new Date()
        });
        res.status(429).json({ error: 'Too many attempts' });
    }
});

// Apply middleware
app.use(MongoSanitize()); // Remove any $ or . characters
app.post('/login', loginLimiter, loginController);

Numbers That Scare (Rightly So)

Based on our monitoring of real projects:

Metric	Value	Impact
Apps vulnerable to NoSQL Injection	67%	🚨 Critical
Average time to fix post-breach	3-6 months	💸 Expensive
Average cost of data breach	€50,000-200,000	💔 Painful
Apps using sanitization	23%	😱 Scary
Developers who test for NoSQL Injection	12%	🤦 Facepalm

The NoSQL Security Checklist

If we started an audit tomorrow, this would be our approach:

Immediate Actions (Day 1)

[ ] Install sanitization libraries
[ ] Implement type checking on all inputs
[ ] Enable detailed logging
[ ] Rate limiting on critical endpoints

Short Term (Week 1)

[ ] Schema validation on all collections
[ ] Safe query builders
[ ] Basic penetration testing
[ ] Team training on NoSQL security

Long Term (Month 1)

[ ] WAF configuration
[ ] Continuous monitoring
[ ] Incident response plan
[ ] Periodic security audits

Essential Tools and Libraries

// The security starter pack
const securityStack = {
    sanitization: [
        'mongo-sanitize',
        'express-mongo-sanitize'
    ],
    validation: [
        'joi',
        'express-validator',
        'ajv'
    ],
    monitoring: [
        'winston',
        'sentry',
        'datadog'
    ],
    testing: [
        'NoSQLMap',
        'Burp Suite',
        'OWASP ZAP'
    ]
};

Red Flags You Should Never Ignore

Warning: If you see this in your code, stop everything and fix it IMMEDIATELY:

// 🚨 DANGER ZONE 🚨
// Direct user input in queries
db.collection.find(req.body.query);

// String concatenation in queries
db.collection.find({ $where: `this.name == '${username}'` });

// No type validation
const data = req.body;
db.collection.insert(data);

// Eval or Function constructor
const query = new Function('return ' + userInput)();

The Moral of the Story

NoSQL Injection isn't black magic. It's a real problem that affects real companies with real (and costly) consequences.

Good news? With the right precautions, it's easier to prevent than it seems. Bad news? Most apps in production lack these precautions.

How Almastack Tackles the Problem

In Almastack, when we build apps that use NoSQL databases, security isn't a "nice to have" — it's the foundation we build on.

Our approach:

Security by Design: Every query is sanitized, every input validated
Continuous Testing: Automated security testing in CI/CD
24/7 Monitoring: Real-time anomaly detection
Training: Your team will know how to recognize and prevent these attacks

Because in the end, a secure app isn't a cost. It's an investment for sleeping well.

P.S. If after reading this article you're rushing to check your MongoDB APIs... good. And if you find something worrying, you know where to find us. 😉

almastack.it

#NoSQL #Security #MongoDB #CyberSecurity #WebDevelopment #Almastack