DEV Community: Swapnil Srivastava

Is Your Node.js App Vulnerable to SSRF? Secure Axios & Fetch in 5 Minutes

Swapnil Srivastava — Tue, 28 Jul 2026 05:42:41 +0000

If your Node.js application accepts user-supplied URLs—whether you are building a webhook system, a link preview feature, or a file uploader—you might be wide open to Server-Side Request Forgery (SSRF).

Most developers think a quick regex check to block localhost or 127.0.0.1 makes them safe.

It doesn't.

An attacker can easily bypass standard string-matching filters using advanced exploitation techniques:

DNS Rebinding: Setting up a custom domain that resolves to a safe public IP on the first lookup (passing your validation) but resolves to a local IP on the second lookup (when your app actually executes the fetch).
Cloud Metadata Exploitation: Accessing internal cloud provider endpoints like AWS IMDSv2 (169.254.169.254) to steal IAM roles, API tokens, and infrastructure credentials.
Internal Subnet Scanning: Forcing your server to act as a proxy to probe private company microservices (10.0.0.0/8 or 192.168.0.0/16).

To solve this problem comprehensively at the network runtime layer, I built ssrf-agent-guard—a lightweight, defensive TypeScript module that hardens http.Agent and https.Agent against runtime exploits.

🔒 Deep Protection via Custom Network Agents

Instead of trying to sanitize unsafe string inputs, ssrf-agent-guard intercepts requests during the actual network cycle. It executes pre-and-post DNS resolution host checks, ensuring your application never communicates with a forbidden destination.

Here is how easily it drops right into Axios:

const ssrfAgentGuard = require('ssrf-agent-guard');

const unsafeUserUrl = 'http://169.254.169';

axios.get(unsafeUserUrl, {
  // Automatically intercept and abort before connections are established
  httpAgent: ssrfAgentGuard(unsafeUserUrl),
  httpsAgent: ssrfAgentGuard(unsafeUserUrl)
})
.then((response) => console.log('Success'))
.catch((error) => console.error('Blocked Securely:', error.message));

It works exactly the same way with native fetch or node-fetch:

fetch(unsafeUserUrl, { agent: ssrfAgentGuard(unsafeUserUrl) });

🛡️ Core Security Capabilities

This package abstracts away complex networking logic into clean, production-grade defenses:

1. Cloud Provider Metadata Detection

It blocks explicit access to cloud environment endpoints across all major infrastructure systems, covering AWS, Google Cloud Platform (GCP), Microsoft Azure, Oracle Cloud, DigitalOcean, and Kubernetes clusters.

2. Built-in DNS Rebinding Mitigation

The agent evaluates the resolved IP addresses right before a socket connection opens. If a malicious domain attempts to switch its resolution from a public address to a restricted internal IP post-validation, the module catches the shift and terminates the request immediately.

3. Policy-Based Domain Filtering

You can configure explicit access rules using strict allowlists, denylists, and top-level domain (TLD) blocking architectures:

const agent = ssrfAgentGuard('https://example.com', {
  mode: 'block',              // Options: 'block' | 'report' | 'allow'
  detectDnsRebinding: true,   // Kill time-of-check to time-of-use exploits
  policy: {
    allowDomains: ['*.trustedpartners.com'], 
    denyDomains: ['untrusted-source.evil'], 
    denyTLD: ['local', 'internal', 'lan'] 
  }
});

📊 Flexible Operation Modes

Securing a legacy system can be intimidating. ssrf-agent-guard includes multiple operation modes so you can safely gauge its impact before turning on enforcement:

block: The default defensive state. Dropping malicious requests instantly.
report: A passive observational mode. It logs violations via a custom handler so you can trace vulnerabilities in your production traffic without breaking current user loops.
allow: Bypasses restrictions entirely for specialized debugging environments.

🛠️ Fully Typed and Production-Tested

The engine is authored completely in TypeScript, bringing full autocompletion support to your IDE. It ships with ready-made architecture guides and implementation examples for major modern web frameworks:

Express.js
Fastify
NestJS

Stop leaving your backend servers open to simple network manipulation. Drop the agent guard into your network configuration stack today:

npm install ssrf-agent-guard

Check out the full security rationale breakdown, read the list of globally restricted IP blocks, and join the development over on GitHub:

👉 GitHub: swapniluneva/ssrf-agent-guard

How is your team currently validating outgoing webhooks or link generation requests? Let's discuss security best practices in the comments below!

Stop Writing Boilerplate API Pagination Loops: Meet lazy-api-paginator

Swapnil Srivastava — Tue, 28 Jul 2026 05:40:49 +0000

We have all written this exact chunk of boilerplate code at least a dozen times:

let nextUrl = 'https://example.com';
const allItems = [];

while (nextUrl) {
  const response = await fetch(nextUrl);
  const json = await response.json();
  allItems.push(...json.items);
  nextUrl = json.next_page_url; 
}

It looks simple, but this naive implementation breaks instantly in production.

What happens when the API hits you with a 429 Too Many Requests error? Your script crashes. What if the dataset contains 500,000 records? Your server runs out of RAM, triggers a memory leak, and throws an Out of Memory panic. What if the API requires cursor, keyset, or Link-header pagination? You are back to rewiring custom loops from scratch.

To solve this once and for all, I built lazy-api-paginator—a lightweight, zero-dependency TypeScript engine designed to stream paginated API data seamlessly using async generators.

🚀 The Core Solution: Lazy Async Data Streams

Instead of pulling thousands of items into local memory before processing them, lazy-api-paginator fetches pages dynamically on-demand. It yields items one-by-one using native JavaScript for await...of loops.

Here is how simple a basic integration looks:

import { createPaginator } from 'lazy-api-paginator';

const paginator = createPaginator<ApiResponse, User>({
  initialUrl: 'https://example.com',
  extractItems: (res) => res.data,
  getNextPageUrl: (res) => res.nextCursor ? `https://example.com?cursor=${res.nextCursor}` : null,
});

// Memory consumption remains constant, no matter how large the API dataset is!
for await (const user of paginator) {
  console.log(`Processing: ${user.name}`);
}

🛠️ Production-Ready Features Built-In

This isn't just a wrapper around fetch. It includes the mission-critical safeguards that production environments demand:

1. Smart Rate Limiting & 429 Handling

The paginator automatically throttles outward requests to match a target rate limit. If it encounters a 429 status code, it intelligently parses standard Retry-After, X-RateLimit-*, or RateLimit-* headers to pause execution before gracefully retrying.

rateLimit: {
  requestsPerSecond: 10,       // Throttles requests safely
  respectRetryAfter: true,     // Automatically honors API headers
  maxRateLimitDelay: 60000     // Maximum wait cap
}

2. Exponential Backoff with Jitter

Network blips happen. The library includes built-in exponential backoff configuration complete with configurable randomness (jitter) to ensure your microservices do not accidentally DDoS your target API endpoints when recovering from a downtime window.

3. Server-Side Request Forgery (SSRF) Protection

If you are passing user-submitted URLs into your backend API integrations, you are exposing yourself to internal network scanning vulnerabilities. lazy-api-paginator provides an optional, pluggable ssrfProtection layer to lock down server-to-server calls away from internal cloud metadata instances (169.254.169.254) and local subnets.

📦 Zero Boilerplate Templates for Common APIs

Different platforms use completely different pagination mental models. The package ships with ready-to-use structural strategies to eliminate manual token plumbing:

Cursor-based: Out-of-the-box configurations mapping straight to the data schemas of Stripe, Slack, and Notion.
Link Headers: Automatic header extraction custom-tailored for the GitHub REST API.
Page number-based: Perfect for applications consuming default frameworks like Laravel or Django.
Offset/Keyset Seek: Highly optimized for traditional database pagination setups.

import { createPaginator, strategies } from 'lazy-api-paginator';

// Zero boilerplate pagination for GitHub Issues
const githubPaginator = createPaginator({
  initialUrl: 'https://github.com',
  ...strategies.linkHeader({ dataPath: '' }),
});

🌟 Open Source & Open to Feedback

lazy-api-paginator works out of the box in both modern ECMAScript Modules (ESM) and legacy CommonJS (CJS) environments with full, native TypeScript autocomplete types.

If you are tired of writing fragile, memory-heavy while loops every time you connect to an external API service, give it a spin:

npm install lazy-api-paginator

Check out the full documentation, lifecycle hooks guides, and feature roadmaps over on the GitHub repository:

👉 GitHub: swapniluneva/lazy-api-paginator

I would love to hear your thoughts! What pagination patterns does your team run into most often? Let me know in the comments below!