When building an API in Node.js, one of the most critical decisions affecting security and user experience is how you handle incoming traffic. Not all visitors are equal: some are legitimate customers browsing from home, others are corporate employees accessing through a VPN, and a few are malicious bots trying to exploit every vulnerability. The traditional approach of waiting for a rate limiter to trigger an alert the next day is reactive and costly. Instead, you can stop unwanted traffic at the door, before it touches a single route handler, by using IP reputation as the first line of defense.
At Q2BSTUDIO, as a company specialized in custom software and cybersecurity solutions, we have implemented this pattern in multiple projects. The idea is simple: every request arrives with an IP address that already has a history. It could be a residential range, a datacenter, a known VPN, or an address that has been brute-forcing for days. If you know what kind of IP you have before executing your business logic, you can decide how to act: block obvious attackers, challenge suspicious ones with a CAPTCHA, or let clean ones through without friction. This granularity is key to not losing real customers through binary decisions.
The middleware presented here is not a generic piece; it is designed to integrate into existing Node.js (18+) flows using Express, and relies on the WhoisFreaks API for real-time reputation data. But the important part is not the API itself, but the decision architecture you build around it. If you operate in cloud environments like AWS or Azure, this approach scales seamlessly thanks to distributed caches with Redis. And if you also integrate AI agents to analyze behavior patterns, you can further refine the rules.
Let us start at the beginning: getting the real client IP. It seems trivial, but in a modern deployment with load balancers or CDNs, req.socket.remoteAddress returns the proxy IP, not the visitor. The real IP is in the X-Forwarded-For header. Express will not read it unless you configure app.set('trust proxy', true). Do it correctly, otherwise attackers can spoof that header and impersonate 127.0.0.1. Once adjusted, we extract the IP by cleaning the ::ffff: prefix that Express adds for IPv4-mapped IPv6 addresses.
The next step is to query the reputation. The API returns a security object with fields like threat_score (0–100), is_vpn, is_proxy, is_tor, is_known_attacker, is_bot, and is_cloud_provider, plus confidence levels. With this rich data you can define four action levels instead of a simple binary block: allow, challenge, step-up authentication, or block. For example, a threat_score of 40 usually corresponds to a datacenter or commercial VPN, where many legitimate users browse; a CAPTCHA challenge is appropriate. Above 75, the traffic is clearly malicious and should receive a 403.
The middleware we implement at Q2BSTUDIO follows a fail-open philosophy: if the reputation API fails (timeout, 500 error), the request goes through. We prefer a small window of risk over a total service outage. We also skip private IPs (localhost, health checks) to avoid wasting credits and slowing internal traffic. For optimization, we cache responses for 12 hours using an in-memory Map, though in production with multiple instances we would replace it with Redis.
Once you have the middleware, you can combine it with other cybersecurity strategies. For example, from our AI agents we can analyze patterns of blocked requests to dynamically adjust score thresholds. You can also enrich logs with the asn and connection_type fields to create your own rules. Additionally, if you use Power BI or BI tools, you can visualize in real time which IPs are blocked, how many pass through the challenge level, and how malicious traffic evolves week over week.
In our tests with 20 IPs extracted from real logs, we found that two Tor exit node entries reached scores of 85 and 80, flagged as known attackers. Most datacenter and VPN IPs clustered around score 50 without individual flags, confirming that a binary decision would have been either excessive or insufficient. The four-tier approach allowed handling each case according to its context.
If you want to implement this protection in your own API, you can start with the WhoisFreaks repository and adapt it to your stack. But remember that IP reputation is just one layer. At Q2BSTUDIO we integrate this kind of middleware with cloud solutions on AWS and Azure, process automation, and BI systems to offer complete and scalable defense. It is not only about blocking bots; it is about doing so without breaking the experience of your real users.
To go deeper, I recommend exploring how artificial intelligence can improve real-time anomaly detection, or how custom software development can incorporate these techniques from the initial design. Proactive security is not a luxury; it is a necessity in today's digital environment.
