Skip to content

Back to the catalog

microsoft/AntiSSRF
github.comrepo

microsoft/AntiSSRF

AntiSSRF is a Microsoft-maintained secure code library (Microsoft.Security.AntiSSRF NuGet package, @microsoft/antissrf npm package) that validates URLs and network connections to prevent Server-Side Request Forgery, including an agent that blocks HTTP requests from reaching internal or sensitive IP ranges. It targets the common vulnerability pattern where user-supplied strings (URLs, filenames, workspace names, resource identifiers) are concatenated into server-side requests without validation, which can lead to internal service exposure, data exfiltration, or token theft.

TL;DR Microsoft's drop-in .NET/Node.js library that validates URLs and blocks requests to internal IPs to mitigate SSRF.
Document

What it is

Microsoft's AntiSSRF is a secure code library that validates URLs and network connections to mitigate Server-Side Request Forgery (CWE-918). It ships for three runtimes: the NuGet package Microsoft.Security.AntiSSRF for .NET, the npm package @microsoft/antissrf for Node.js, and the PyPI package microsoft-antissrf for Python. The existing summary names only the first two. The repo links API docs, a getting-started guide and a README for each runtime.

How it works

The library rejects unsafe input during URL and connection validation. It also provides an agent that stops HTTP requests from reaching internal or sensitive IP addresses. The page gives no API names, configuration options or code samples, so how to call either component is only in the linked per-language docs.

Preconditions / Affected

The page sets a wide scope for what counts as untrusted input and so must be validated:

  • User-provided URLs, filenames and identifiers.
  • Data from external APIs, webhooks and partner services.
  • Configuration values, metadata and file contents that users can influence.
  • Requests from your own backend components in the same environment.
  • Strings that are not obviously URLs but get concatenated into one, such as a workspace name or resource identifier.

The last two items are the ones most often skipped. Internal callers and "non-URL" fields are in scope under this guidance.

What to do

Add the package for your runtime and read its getting-started guide for the validation calls and the agent setup. For dynamic testing, the page points to Dusseldorf, a separate Microsoft open-source tool for SSRF testing and validation. Dusseldorf can check whether the library is actually wired into every request path.

Caveats

The page has no benchmarks, version boundaries or bypass analysis. It describes the library as "exhaustively-tested" without evidence. Coverage and behaviour, such as how redirects or DNS rebinding are handled, are not stated and must be checked in the docs.

Organisations named here

  • CWE-918

Technologies named here

  • AntiSSRF
  • Dusseldorf
  • .NET
  • Node.js
  • NuGet
  • npm

Techniques named here

  • SSRF