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?
Top comments (0)