The Security Bug Every Node.js Developer Ships to Production

Last year I was doing a code review for a startup. Everything looked fine on the surface, clean code, good structure, tests passing.

Then I noticed this:

const query = `SELECT * FROM users WHERE email = '${req.body.email}'`

That's it. That's the bug. SQL injection, sitting right there in a startup that had been in production for 8 months.

Nobody caught it. Not the developer, not the reviewer, not the CTO.

Here's the thing, it's not that developers are careless. It's that this kind of bug is invisible until it isn't. The code works perfectly. Tests pass. Users are happy. Until someone types ' OR '1'='1 in the email field and walks straight into your database.

The bugs I see most often

1. Raw SQL with user input

// 🚨 This is everywhere
const query = `SELECT * FROM users WHERE email = '${email}'`

// ✅ Use parameterized queries
const query = 'SELECT * FROM users WHERE email = $1'
db.query(query, [email])

2. Secrets in environment variables... committed to git

# .env
DATABASE_URL=postgres://user:[e-mail]/mydb
STRIPE_SECRET=sk_live_...

Then .env ends up in the repo because someone forgot to add it to .gitignore. I've seen this more times than I want to admit. GitHub's secret scanning catches some of these, but not always before someone has already cloned the repo.

3. JWT tokens that are never actually verified

// 🚨 Decoding is not the same as verifying
const user = jwt.decode(token)

// ✅ Always verify
const user = jwt.verify(token, process.env.JWT_SECRET)

jwt.decode just reads the token. Anyone can forge it. jwt.verify actually checks the signature. The names are confusingly similar and the wrong one silently works in development.

4. No rate limiting on auth endpoints

// 🚨 Anyone can try a million passwords
app.post('/login', async (req, res) => {
  const user = await db.findUser(req.body.email)
  // ...
})

// ✅ Add rate limiting
const authLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 10
})
app.post('/login', authLimiter, async (req, res) => {
  // ...
})

Without rate limiting, a brute force attack costs nothing. With it, 10 failed attempts and you're blocked for 15 minutes.

5. Error messages that reveal too much

// 🚨 Tells attackers exactly what's wrong
catch (error) {
  res.status(500).json({ error: error.message })
  // "relation 'users' does not exist"
  // "invalid input syntax for type uuid"
}

// ✅ Log internally, send generic message
catch (error) {
  console.error(error)
  res.status(500).json({ error: 'Something went wrong' })
}

Stack traces and database error messages are gold for anyone trying to map your system.

The one question that catches most of these

Before shipping any endpoint that touches user input, ask:

"What happens if someone sends me something I'm not expecting?"

Empty string. Null. A 10,000 character string. SQL characters. A valid email that belongs to a different user.

Most security bugs aren't sophisticated. They're just cases nobody thought about.

What's the most embarrassing security bug you've found in production, yours or someone else's?

Comments

[Mudassir Khan]

the jwt.decode vs jwt.verify one is the trap that bites the most because it silently works in dev. the decode path returns a valid user object, the test passes, and you ship it. we caught one of these in staging when someone on the team added a token expiry check and noticed the exp field was in the past but the request still went through.

the sneakier variant: libraries that wrap verify but accept 'none' as the algorithm if you don't pin it explicitly. algorithmic agility is a design mistake in this context.

is there a linter or static analysis rule you've found that reliably flags the decode/verify swap before it gets to review?

[Lolo]

The 'none' algorithm trap is nastier because it's not even a mistake. the library just does what you tell it.

For the decode/verify swap, eslint-plugin-security catches some of it but honestly a good code review checklist is more reliable. Linters produce too many false positives on JWT stuff to be trusted blindly.

[Mudassir Khan]

the false positive thing is what makes jwt lint rules especially tricky — teams start suppressing them and then the one real issue gets suppressed too.

we ended up putting the check in a shared wrapper that throws if the decoded header algorithm isn't in an allowlist. boring, but it's the only gate that doesn't need a code review to enforce.

does your checklist live in the PR template, or is it a separate security sign off step?

[leob]

Good overview!

Honestly, almost all of these are pretty basic OWASP items - it requires a dev with very low or non-existent security awareness to make these errors, so I'm a little bit surprised at the article header "The Security Bug Every Node.js Developer Ships to Production" ... :-)

[Lolo]

Fair point, the title is a bit dramatic 😅

But "basic" and "ships to production anyway" aren't mutually exclusive. I've seen senior devs with OWASP memorized push jwt.decode to prod on a Friday afternoon. Deadline pressure is a hell of a drug.

[leob]

Haha yeah that's true, and the jwt.decode !== jwt.verify point is definitely a good call !

[𝑻𝒉𝒆 𝑳𝒂𝒛𝒚 𝑮𝒊𝒓𝒍]

Great article!
I think this is one of those security issues many developers accidentally overlook because the code still "works" during testing. The examples made it really easy to understand why trusting user input can become dangerous in production.

What I liked most is that you didn't just point out the problem—you also showed practical ways to avoid it. Posts like this are a good reminder that security isn't something we add later; it's part of writing good code from the start.

Thanks for sharing! ❤️

[Lolo]

Exactly, security should be part of the first review, not a "we'll add it later" item. The scary part is that most of these bugs don't throw errors, they just sit there waiting.

Thanks for reading! 🙏

[Frank]

Interesting point about common Node.js security pitfalls

[Lolo]

Thanks!