DEV Community: Davanesh Saminathan

I Got Tired of Installing 5 Security Packages in Every Express Project

Davanesh Saminathan — Tue, 02 Jun 2026 11:08:13 +0000

Every time I started a new Express.js project, the first few minutes looked exactly the same.

npm install helmet
npm install express-rate-limit
npm install morgan

Then came the setup.

Different middleware.

Different configuration options.

Different documentation.

The process wasn't difficult, but after doing it repeatedly across multiple projects, it started to feel unnecessary.

I wasn't building new features.

I was rebuilding the same security foundation over and over again.

The Pattern I Kept Seeing

Most Express applications need the same baseline protections:

Security headers
Rate limiting
Request size limits
Request logging
Secure defaults

Yet every project required installing and configuring multiple packages just to reach that baseline.

For experienced developers, that's manageable.

For beginners, it's often confusing.

And in many projects, security gets postponed until much later in development.

Sometimes it never gets added at all.

What If It Was Just One Package?

At some point, I started asking a simple question:

Why am I repeating the same setup every time?

What if the common security protections could be enabled with a single middleware?

Something as simple as:

import { fortress } from "fortressjs";

app.use(fortress());

That question eventually led to the creation of FortressJS.

Building FortressJS

FortressJS started as a personal project to simplify Express API security.

The goal wasn't to replace every security package in the Node.js ecosystem.

The goal was much simpler:

Provide sensible security defaults with minimal setup.

Today, FortressJS includes:

Security headers
Rate limiting
Request size protection
Request logging
Easy Express integration

Installation:

npm install fortressjs

Usage:

import express from "express";
import { fortress } from "fortressjs";

const app = express();

app.use(fortress());

What I Learned Building It

Building FortressJS taught me several lessons.

Simplicity Is a Feature

Developers don't want more configuration.

They want fewer decisions.

Reducing setup complexity can be just as valuable as adding new functionality.

Scope Can Kill Projects

My initial ideas were much larger.

Threat intelligence.

Security dashboards.

Advanced monitoring.

But trying to build everything at once is how many projects fail.

Starting small made it possible to actually ship something.

Open Source Is Different

Writing code is only part of the work.

Documentation, examples, testing, and feedback are just as important.

A project nobody understands won't get used, regardless of how good the code is.

What's Next?

The roadmap for FortressJS currently includes:

Threat detection
Security auditing CLI
Security scoring
Local monitoring dashboard

The focus remains the same:

Make API security easier for Node.js developers.

Final Thoughts

FortressJS started because I was tired of repeating the same security setup in every Express project.

Instead of doing it again, I decided to build a tool that could automate the process.

The project is still in its early stages, and feedback is always welcome.

⭐ GitHub: https://github.com/davanesh/fortressjs

📦 NPM Packages:

Core: https://www.npmjs.com/package/@fortressjs/core — The main FortressJS package that provides security middleware, rate limiting, request protection, and secure defaults for Express applications.
CLI: https://www.npmjs.com/package/@fortressjs/cli — Command-line tool for auditing, analyzing, and managing FortressJS security features.

If you're building Express APIs, what security package do you install first?

10 Security Mistakes Most Express APIs Make (And How to Fix Them)

Davanesh Saminathan — Tue, 02 Jun 2026 10:41:05 +0000

Building APIs with Express.js is fast and enjoyable, but security is often treated as something to handle later. Unfortunately, small security mistakes can expose applications to attacks, data leaks, and service disruptions.

In this article, we'll look at 10 common security mistakes developers make when building Express APIs and how to fix them.

1. Not Using Security Headers

By default, Express does not add many security-related HTTP headers.

Without proper headers, applications may be vulnerable to attacks such as clickjacking and MIME-type sniffing.

Fix

Install Helmet:

npm install helmet

Use it in your application:

import helmet from "helmet";

app.use(helmet());

2. No Rate Limiting

Without rate limiting, attackers can spam endpoints, brute-force login forms, or overwhelm your server.

Fix

npm install express-rate-limit

import rateLimit from "express-rate-limit";

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
});

app.use(limiter);

3. Exposing Stack Traces in Production

Detailed error messages may reveal sensitive implementation details.

Bad Example

res.status(500).json({
  error: err.stack,
});

Better

res.status(500).json({
  error: "Internal Server Error",
});

Keep detailed logs on the server, not in client responses.

4. Trusting User Input

Never trust incoming data.

Attackers can send malformed requests, inject malicious payloads, or bypass assumptions.

Fix

Validate all incoming requests using libraries such as:

Zod
Joi
express-validator

Example:

const schema = z.object({
  email: z.string().email(),
});

5. Hardcoding Secrets

One of the most common mistakes is storing secrets directly in source code.

Avoid

const API_KEY = "my-secret-key";

Better

const API_KEY = process.env.API_KEY;

Store secrets in environment variables instead.

6. Missing Request Size Limits

Attackers can send extremely large payloads and consume server resources.

Fix

app.use(express.json({
  limit: "1mb",
}));

Choose limits appropriate for your application.

7. Using Outdated Dependencies

Security vulnerabilities are regularly discovered in npm packages.

Fix

Run:

npm audit

And keep dependencies updated:

npm update

8. Weak Authentication Practices

Common mistakes include:

Weak passwords
Long-lived tokens
Missing password hashing
No multi-factor authentication

Fix

Use:

bcrypt or Argon2 for password hashing
JWT expiration times
MFA where appropriate

9. No Logging or Monitoring

If an incident occurs, logs are often the only way to understand what happened.

Fix

Implement structured logging:

import morgan from "morgan";

app.use(morgan("combined"));

Monitor unusual traffic patterns and failed authentication attempts.

10. Assuming HTTPS Is Optional

HTTP traffic can be intercepted and modified.

Fix

Always use HTTPS in production.

If you're deploying behind a reverse proxy:

app.set("trust proxy", 1);

And enforce HTTPS wherever possible.

Final Thoughts

Security isn't a feature you add at the end of a project. It should be part of the development process from day one.

The good news is that most of these issues can be fixed with just a few lines of code.

While exploring common Express security challenges, I've also been building FortressJS, an open-source project focused on making API security easier for Node.js developers.

What security mistake do you see most often in Express applications?

Thanks for reading! 🚀