Hey there, fellow developers! 👋
We all know security isn't just a "DevOps thing" or a "security team thing"—it's a core part of building good software. Yet, under tight deadlines or in the heat of a complex feature, it's easy to slip up. Based on what I've seen in projects big and small, there are a handful of security mistakes that just keep popping up.
Let's dive into five of the most common security blunders and, more importantly, lay out the practical, code-level fixes we can implement today using Node.js examples.
1. Trusting User Input (The Classic Blunder)
This one is ancient, but it never dies. Whether it's data from a web form, a URL parameter, or a JSON payload, all user input is hostile until proven otherwise. Failing to treat it as such is the fast track to vulnerabilities like SQL Injection or Cross-Site Scripting (XSS).
🛠️ The Fix: Parameterization and Sanitization
Use cases:
Mistake 1: SQL Injection - Directly concatenating user input into a database query string.
Solution: Use Parameterized Queries/Prepared Statements. When working with a database like PostgreSQL or MySQL in Node.js, libraries like pg or mysql2 support parameterized queries that separate the SQL logic from the data. An attacker's input is treated only as a value, not executable code.
Mistake 2: XSS: Displaying user-submitted text directly on a web page (e.g., a forum post).
Solution: Escape Output. Before rendering user data in the browser, always escape special characters (like <, >, &). Use template engines that auto-escape (like Handlebars or Pug) or dedicated libraries like dompurify if you must allow some HTML.
Sample Code:
// MISTAKE: SQL Injection Risk
// const user = 'admin\' OR \'1\'=\'1';
// connection.query(`SELECT * FROM users WHERE username = '${user}'`, (err, results) => { ... });
// FIX: Parameterized Query (The data is never mixed with the query structure)
const user = 'admin\' OR \'1\'=\'1';
const sql = 'SELECT * FROM users WHERE username = ?'; // Use a placeholder
connection.execute(sql, [user], (err, results) => {
// The malicious input is treated as a safe string value.
if (err) throw err;
console.log(results);
});
This is the single most important rule of secure coding: Input Validation, Output Encoding.
2. Leaving Default/Insecure Configurations in Place
Every time you spin up a new service, a database, a cloud function, or a web framework (like Express) it comes with default settings. Often, these defaults are designed for ease of use or local development, not for production security. Things like default credentials, permissive firewall rules, or having debugging mode enabled fall into this category.
🛠️ The Fix: Principle of Least Privilege & Hardening
- Change all Default Credentials: Use a secrets manager (like HashiCorp Vault or AWS Secrets Manager) and complex, unique credentials.
- Disable Unnecessary Features: Turn off features you don't need. For Express apps, use the helmet middleware to set secure HTTP headers, which is a massive win for minimal effort.
- Implement the Principle of Least Privilege (PoLP): Your Node.js process should only have the minimum permissions it needs to function. Don't run your application as the root user.
Code Example (Node.js with Express and Helmet):
// Protects your app from some well-known web vulnerabilities
// by setting HTTP headers appropriately.
const express = require('express');
const helmet = require('helmet');
const app = express();
app.use(helmet());
app.get('/', (req, res) => {
res.send('Hello Secure World!');
});
// A simple but critical step for web hardening!
3. Ignoring Dependency Vulnerabilities (The Supply Chain Risk)
We all rely on open-source packages, it's how modern development works. But every package you add (via npm install) is a potential entry point for an attacker.
You might be focused on writing secure application code, but if a third-party package you rely on has a critical vulnerability (a major issue with your node_modules!), your entire app is at risk.
🛠️ The Fix: Automation and Regular Audits
- Use Software Composition Analysis (SCA) Tools: Utilize the built-in npm audit command. It automatically scans your package-lock.json against a public vulnerability database. Tools like Dependabot (for GitHub) or Snyk can also be integrated into your CI/CD pipeline.
- Regular Updates: Make updating your dependencies a routine. Running npm audit fix regularly is much easier than scrambling when a major CVE (Common Vulnerabilities and Exposures) is announced.
- Delete Unused Dependencies: If you're not using a library anymore, run npm uninstall . Less code, less risk.
Terminal Command Example:
# Run this command often!
npm audit
# To automatically fix safe vulnerabilities
npm audit fix
4. Storing Secrets Directly in Code (The Git Blunder)
Storing API keys, database connection strings, or encryption keys directly in your source code is a critical mistake. It's often the first place an attacker looks after compromising a developer's machine or gaining access to a private repo.
🛠️ The Fix: Environment Variables and Dedicated Managers
- Use Environment Variables: At a minimum, load secrets from environment variables using a library like dotenv. This keeps secrets out of the codebase by placing them in a .env file that is added to your .gitignore.
- Adopt a Secrets Manager: For production, use a dedicated solution like AWS Secrets Manager, Azure Key Vault, or Kubernetes Secrets.
- Pre-commit Hooks: Use tools like git-secrets to scan your code before it's committed to prevent accidentally pushing sensitive information.
Code Example (Node.js with dotenv):
// .env file (NEVER commit this to Git)
// DB_USER="my_secure_user"
// DB_PASS="long_random_password_123"
// server.js (loads secrets from .env or system environment)
require('dotenv').config();
const dbUser = process.env.DB_USER;
const dbPass = process.env.DB_PASS;
if (!dbUser || !dbPass) {
throw new Error("Database credentials not found in environment variables!");
}
// Now safely use dbUser and dbPass for your connection logic...
5. Broken Authentication/Authorization (The "Who Can Do What" Problem)
These two are often confused:
- Authentication: Who are you? (Logging in)
- Authorization: What are you allowed to do? (Accessing resources)
A common mistake is forgetting to check authorization on every server-side API endpoint. For example, an attacker might log in as a standard user, then call a backend API endpoint that's only supposed to be accessible by an administrator. If the API doesn't have a check to see if the authenticated user has the "admin" role, you have a Broken Access Control vulnerability.
🛠️ The Fix: Deny-by-Default and Express Middleware
- Deny-by-Default: Structure your authorization logic so that a user is denied access unless they are explicitly granted permission.
- Use Server-Side Checks (Always!): Never rely solely on client-side (frontend) checks to hide or disable features. Your API must validate the user's rights for every resource request.
- Implement Authorization Middleware: Use Express middleware to check roles before the main route handler executes.
Code Example (Node.js with Express Middleware):
// Middleware to check for the 'admin' role
const requireAdmin = (req, res, next) => {
// Assume req.user object is populated after authentication
// CRITICAL SERVER-SIDE CHECK
if (req.user && req.user.role === 'admin') {
next(); // User is an admin, proceed to the route handler
} else {
// Stop the request immediately
res.status(403).json({ message: 'Forbidden: Insufficient privileges' });
}
};
// Apply the check to the sensitive route
app.delete('/api/users/:id', requireAdmin, (req, res) => {
// This code only runs if the user is an admin
// ... logic to delete user ...
res.status(204).send();
});
Final Thoughts: Shift Left and Stay Curious
The best security practice is adopting a "Shift Left" mentality catching these issues as early as possible. Don't wait for a penetration test; build security into your code review process and daily habits.
Security is a constant learning process. What other security mistakes have you seen or fixed recently? Let me know in the comments! 👇
Top comments (0)