How I Built Security Middleware for Express: SQL Injection, XSS, Rate Limiting, and IP Reputation

Sandeep Sharma — Sat, 29 Aug 2026 14:23:13 +0000

How I Built Security Middleware for Express: SQL Injection, XSS, Rate Limiting, and IP Reputation

Security in an Express application can quickly become a collection of separate middleware packages and configuration rules.

I wanted to experiment with a different approach: a single middleware that evaluates incoming requests using multiple detection rules and assigns a risk score rather than making every security decision as a simple yes/no check.

That experiment became SecurityWatch.

What is SecurityWatch?

SecurityWatch is score-based runtime security middleware for Express.

It currently detects and evaluates:

SQL injection patterns
XSS patterns
Brute-force behavior
Rate-limit abuse
Suspicious request behavior
Payload anomalies
IP reputation

The project is available on NPM:

https://www.npmjs.com/package/securitywatch

The source code is on GitHub:

https://github.com/sandeepsharmacode/securitywatch

Installation

SecurityWatch requires:

Node.js 18 or newer
Express 5 or newer

Install it with:

npm install securitywatch

Then add it to an Express application:

import express from "express";
import { securityWatch } from "securitywatch";

const app = express();

app.use(securityWatch());

app.listen(3000);

That's the basic setup.

How the scoring system works

Instead of treating every suspicious pattern as an automatic block, SecurityWatch gives each detection rule a numeric score.

The scores are combined and then evaluated against configurable thresholds.

The default behavior is:

Score	Action
0–4	Allow
5–9	Warn
10–14	Throttle with HTTP 429
15+	Block with HTTP 403

For example, a request might contain a suspicious pattern that isn't serious enough on its own to block.

Rather than immediately rejecting it, the middleware can assign a warning-level score.

This gives the application more room to distinguish between suspicious activity and clearly malicious behavior.

Route sensitivity

Not every endpoint has the same security requirements.

A public search endpoint and an administrator endpoint shouldn't necessarily have identical thresholds.

SecurityWatch therefore supports route sensitivity:

routeSensitivity: {
  "/admin": "critical",
  "/login": "high",
  "/search": "low",
}

The available levels are:

low — 0.5×
medium — 1×
high — 1.5×
critical — 2×

This allows the same detection rules to have different effective sensitivity depending on the route.

Configuring the middleware

A more complete configuration can look like this:

app.use(securityWatch({
  sqlInjection: true,
  xss: true,

  bruteForce: {
    maxAttempts: 5,
    windowMs: 5 * 60_000,
    blockDurationMs: 15 * 60_000,
    authRoutes: ["/login", "/auth"],
  },

  rateLimit: {
    windowMs: 60_000,
    maxRequests: 100,
    routes: {
      "/login": 5,
      "/api": 60,
    },
  },

  suspiciousBehavior: true,
  payloadAnomaly: true,
  ipReputation: true,

  routeSensitivity: {
    "/admin": "critical",
    "/login": "high",
    "/search": "low",
  },

  thresholds: {
    warn: 5,
    throttle: 10,
    block: 15,
  },

  whitelist: ["127.0.0.1"],

  trustProxy: false,

  onBlock: (req, info) => {
    console.log(`Blocked: ${info.ip}`);
  },

  onWarn: (req, info) => {
    console.log(`Warning: ${info.ip}`);
  },
}));

Why I chose scoring instead of binary blocking

A simple security rule might look like:

suspicious pattern detected → block request

The problem is that real application traffic isn't always that simple.

A request can contain something unusual without necessarily being an attack.

A scoring system allows multiple signals to contribute to the final decision.

For example:

Rule A → +3
Rule B → +2
Route sensitivity → applied
-------------------------
Final score → evaluated against thresholds

The intention is to reduce unnecessary blocking while still allowing clearly suspicious requests to cross a stronger threshold.

Brute-force protection

SecurityWatch can also track repeated authentication attempts.

For example:

bruteForce: {
  maxAttempts: 5,
  windowMs: 5 * 60_000,
  blockDurationMs: 15 * 60_000,
  authRoutes: ["/login", "/auth"],
}

This allows authentication routes to have their own attempt limits and temporary blocking behavior.

Rate limiting

Rate limiting can be configured globally and for specific routes:

rateLimit: {
  windowMs: 60_000,
  maxRequests: 100,
  routes: {
    "/login": 5,
    "/api": 60,
  },
}

This is useful when sensitive endpoints need stricter limits than ordinary API traffic.

Security considerations

Because this is security middleware, there are several implementation details worth mentioning.

Input is truncated before scanning, with a maximum of 20,000 characters.

The detection regexes use bounded quantifiers to help prevent problematic behavior from excessively large inputs.

The middleware also limits its in-memory tracking:

IP tracking is capped at 10,000 entries.
Route tracking is capped at 100 routes per IP.
Rate-limit keys are normalized.

By default, X-Forwarded-For isn't trusted.

If the application is behind a trusted reverse proxy, trustProxy can be enabled:

trustProxy: true

This should only be enabled when the proxy configuration is actually trusted.

Alerts

SecurityWatch can also expose security events through callbacks such as:

onBlock: (req, info) => {
  console.log(`Blocked: ${info.ip}`);
},

onWarn: (req, info) => {
  console.log(`Warning: ${info.ip}`);
},

The configuration also supports console alerts and Slack webhook configuration.

Fail-open behavior

One design decision I made was to catch internal middleware errors and allow the request to proceed while logging the error.

That means an internal SecurityWatch failure should not automatically become an application-wide outage.

This is a deliberate trade-off and is something I expect to continue evaluating as the project develops.

Is this a replacement for every security package?

No.

SecurityWatch is an experiment in combining runtime request detection and abuse controls into one Express middleware.

It shouldn't be treated as a replacement for secure application design, parameterized database queries, output encoding, authentication, authorization, HTTPS, secure headers, dependency management, or other appropriate security controls.

In particular, SQL injection should still be prevented at the database/query layer rather than relying solely on pattern detection.

What's next?

The project is still young, and I'm particularly interested in improving:

Detection accuracy
False-positive handling
Performance
Rule quality
Configuration ergonomics
Testing against realistic application traffic

If you're an Express or Node.js developer, I'd be interested in hearing how you'd approach the architecture and what security cases you think are missing.

SecurityWatch:

NPM: https://www.npmjs.com/package/securitywatch

GitHub: https://github.com/sandeepsharmacode/securitywatch

Website: https://securitywatch.sandeepsharmadev.in