DEV Community: Sanoy24

How MCP fetch servers keep getting SSRF wrong (and how I tried not to)

Sanoy24 — Tue, 11 Aug 2026 13:58:36 +0000

If you give an AI agent a tool that fetches URLs, you've given it a tool that
can be pointed at your own infrastructure. That's not a hypothetical — it's
one of the most common real vulnerability classes showing up in MCP servers
right now, and the fixes that "obviously" work keep quietly failing on the
same handful of edge cases.

I spent the last few weeks building safe-fetch-mcp-server,
an MCP server whose entire job is fetching a URL and returning clean
markdown — and whose entire point is refusing to do that when the URL
points somewhere it shouldn't. This is the story of what actually made that
hard, a bug that only showed up once I stopped trusting my own test suite,
and how I tried to prove the thing works instead of just asserting it.

The problem in one sentence

An agent that can fetch arbitrary URLs on your behalf can be tricked into
fetching http://169.254.169.254/latest/meta-data/ — the cloud metadata
endpoint every major provider exposes — and handing your instance
credentials to whoever wrote the page that told it to. The most widely used
reference fetch server ships with no SSRF protection at all, by its own
README's admission. Several of the "secure" community alternatives have
shipped real CVEs anyway: an IPv6 check that missed the IPv4-mapped loopback
form (::ffff:127.0.0.1), a background poller that re-fetched a URL through
a code path the original SSRF guard never touched.

That second one stuck with me. It's not a hard bug to imagine — you write the
guard, you wire it into the code path you're looking at, and eighteen months
later someone adds a "refresh this URL periodically" feature that calls a
slightly different function three files away. The guard was never wrong. It
just wasn't everywhere.

The principle that actually holds up

Hostname-string checks fail for two structural reasons: IP address encodings
are effectively infinite (2130706433, 0x7f000001, 0177.0.0.1, and
127.0.0.1 are the same address), and a hostname can legitimately resolve to
something completely different on the next lookup — DNS rebinding, where an
attacker's domain answers with a public IP the first time your validator
checks it, then a private one the moment you actually connect.

The only approach that closes both holes: validate the resolved IP, never
the hostname string, and pin the connection to that exact IP. Resolve
once. Check the address you got back against explicit blocked ranges — not a
library's opinion of what's "private," explicit ranges you wrote yourself,
because the most popular IP-classification package on npm has itself shipped
an SSRF-bypass CVE. Then connect to that address, not to "whatever this
hostname resolves to right now."

That last part is the one people skip, because it's the one Node makes
inconvenient.

The bug that only showed up in production

Node's global fetch — and the http/https clients by default — will
re-resolve DNS at connection time regardless of what you validated a moment
earlier. So the fetch server doesn't use them. It resolves the hostname
itself, validates the result, and passes a custom DNS lookup function into
http.request() that always answers with that one already-validated
address, no matter what hostname it's asked about. The socket physically
cannot connect anywhere else.

I wrote sixty-two tests for this. Every threat-matrix row had a green check
mark. And the very first time I drove a real HTTPS request through a real
MCP client instead of my own test fixtures, it failed with:

Invalid IP address: undefined

...four stack frames deep inside Node's TLS socket code, nowhere near
anything I'd written. It took a debugging session to work out why: Node
enables Happy Eyeballs (dual-stack connection racing) by default, and when
it's active, the HTTP client calls your custom lookup function with
{ all: true } and expects an array of addresses back — not the single
string every piece of documentation I'd read implied. My function always
returned a bare string. Node silently misread it, and the failure surfaced
somewhere completely unrelated to the actual bug.

The fix was three lines — branch on options.all, return the shape the
caller actually asked for. The lesson was bigger: a mocked test suite proves
your logic is internally consistent. It doesn't prove Node's real networking
stack agrees with your assumptions about its own API. I only found this by
refusing to ship until I'd watched a real fetch succeed against a real HTTPS
site, not just a local fixture server standing in for one.

Proving it, not asserting it

"Secure by design" is a claim anyone can make. I wanted evidence, so once
the core was built I ran agent-audit-kit —
an independent, 276-rule static scanner for MCP servers — against the whole
repository.

First run: 13 findings. Two critical.

That's a real number, and I'm not going to pretend it wasn't a gut-check
moment for a project whose whole pitch is "provably correct." But the
interesting part wasn't the count — it was what the findings actually were
once I read the scanner's own rule source instead of just its output
message.

The critical one turned out to be a false positive with a genuinely
interesting cause: the rule pattern-matches for literal tokens like
allowedHosts: in your source to confirm you're guarding against DNS
rebinding on the HTTP transport. I was guarding against it — through the
MCP SDK's newer createMcpExpressApp() helper, which handles Host-header
validation internally and never requires you to write that literal token
yourself. The scanner's rule predates that API. Rather than just noting
"false positive" and moving on, I made the code strictly better anyway:
passed the allow-list explicitly instead of relying on the SDK's implicit
host-based auto-detection, which closed a real edge case (the protection
used to silently disable itself if you ever pointed the server at a
non-default host) and satisfied the scanner honestly, because now the
protection really was explicit.

Two more findings were genuinely real: the npm dependency was pinned to a
version range wide enough to include builds from before the DNS-rebinding
fix landed upstream, and the HTTP transport had no rate limiting at all — a
real gap, fixed with express-rate-limit and a test proving a 429 on the
third request over a two-request limit.

The rest were legitimate false positives — a scanner keyword-matching
169.254.169.254 and the word "bypassed" inside my own security
documentation, which describes those exact things because that's what the
documentation is for. I documented every exclusion with a written
justification rather than silently suppressing them, because "trust me, it's
fine" is exactly the failure mode a scanner exists to catch.

Final result: 2 findings, zero critical or high. The two that remain are
a dependency-count threshold (normal for any TypeScript project with a real
dev toolchain) and a generic "audit your SDK's scope" nudge that fires for
any project depending on the MCP SDK at all. Both documented, both accepted,
neither hideable.

What I'd tell someone building one of these

Don't trust hostname strings, ever — not even after you've "validated" them. The only thing worth checking is the resolved IP, and the only way to make that check mean anything is to connect to the exact address you checked.
Mocked tests prove your logic. They don't prove your assumptions about the runtime. Drive at least one real request through a real client before you believe your own test suite.
Run an external scanner and read its source, not just its output. A 13-to-2 story is more credible than a 0-finding scan on day one would have been, because it shows the process, not just the destination.
A guard that isn't in exactly one code path will eventually be bypassed. The single most common real-world SSRF regression is a second fetch path someone adds later without realizing the first one was ever guarded at all.

Try it

{
  "mcpServers": {
    "safe-fetch": {
      "command": "npx",
      "args": ["-y", "safe-fetch-mcp-server"]
    }
  }
}

npm: safe-fetch-mcp-server
Source: github.com/Sanoy24/safe-fetch-mcp-server
MCP Registry: io.github.Sanoy24/safe-fetch
Full security write-up, threat matrix, and scan evidence: SECURITY.md

MIT licensed. Issues and PRs welcome — especially if you find the next edge
case I didn't.

Building a Robust E-Commerce API with FastAPI: A Deep Dive

Sanoy24 — Thu, 20 Nov 2025 18:28:21 +0000

In the world of modern web development, FastAPI has emerged as a superstar framework for building high-performance APIs with Python. Its speed, ease of use, and automatic documentation make it an ideal choice for complex applications like e-commerce platforms.

In this post, I'll take you through the journey of building a comprehensive E-Commerce RESTful API using FastAPI. We'll explore the architecture, key features, and dive into some code to see how it all comes together.

Why FastAPI for E-Commerce?

E-commerce systems require reliability, speed, and scalability. FastAPI checks all these boxes:

High Performance: On par with NodeJS and Go (thanks to Starlette and Pydantic).
Type Safety: Built on Python 3.10+ type hints, reducing bugs and improving editor support.
Auto-Documentation: Generates interactive Swagger UI and ReDoc automatically.
Async Support: Native support for asynchronous programming, perfect for I/O-bound tasks like database queries.

Project Overview

Our project is a fully functional backend for an online store. It's designed to be modular, scalable, and secure.

Key Features

User Management: Secure registration and login with JWT (JSON Web Tokens) and Argon2 hashing.
Product Catalog: Hierarchical category structure and detailed product management.
Shopping Cart: Persistent cart functionality for users.
Order Processing: Complete lifecycle management from order creation to history.
Reviews & Ratings: Allow users to leave feedback on products.
Address Management: Handling shipping and billing addresses.

The Tech Stack

Framework: FastAPI
Database: SQLAlchemy (ORM) + Alembic (Migrations)
Validation: Pydantic
Authentication: PyJWT + Argon2-cffi
Logging: Loguru
Deployment: Docker support included

Architecture & Structure

I've adopted a clean, modular structure to keep the codebase maintainable:

app/
├── api/          # Route handlers (v1/)
├── core/         # Config and security
├── crud/         # Database operations
├── db/           # Session management
├── models/       # SQLAlchemy models
├── schema/       # Pydantic schemas
├── services/     # Business logic
└── main.py       # Entry point

This separation of concerns ensures that our business logic is decoupled from the API layer, and database models are distinct from the API schemas.

Code Deep Dive

Let's look at some interesting parts of the implementation.

1. The Product Model (`app/models/product.py`)

We use SQLAlchemy 2.0 style with Mapped and mapped_column for a modern, type-hinted definition.

class Product(Base):
    __tablename__ = "products"

    id: Mapped[int] = mapped_column(primary_key=True, autoincrement=True)
    name: Mapped[str] = mapped_column(String(255), nullable=False)
    slug: Mapped[str] = mapped_column(String(255), unique=True, nullable=False)
    price: Mapped[float] = mapped_column(Numeric(10, 2), nullable=False)
    stock_quantity: Mapped[int] = mapped_column(default=0)

    # Relationships
    category: Mapped["Category"] = relationship("Category", back_populates="products")
    reviews: Mapped[List["Review"]] = relationship(
        "Review", back_populates="product", cascade="all, delete-orphan"
    )

2. Clean Routing (`app/api/v1/init_routes.py`)

Instead of cluttering main.py, we centralize our route registration. This makes it easy to add new modules or version our API.

def init_routes(app: FastAPI):
    app.include_router(router=healthcheck.router, prefix="/healthcheck")
    app.include_router(router=user.router, prefix="/users")
    app.include_router(router=category.router, prefix="/category")
    app.include_router(router=product.router, prefix="/product")
    app.include_router(router=cart.router, prefix="/cart")
    app.include_router(router=order.router, prefix="/order")

3. Robust Application Setup (`app/main.py`)

Our main.py handles middleware, exception handlers, and metadata configuration.

app = FastAPI(
    title="E-Commerce Backend API",
    description="RESTful API for managing the product catalog...",
    version="1.0.0",
    docs_url="/docs",
    redoc_url="/redoc",
)

app.add_middleware(LoggingMiddleware)

@app.exception_handler(RequestValidationError)
async def validation_exception_handler(request: Request, exc: RequestValidationError):
    # Custom error formatting
    return JSONResponse(
        status_code=status.HTTP_422_UNPROCESSABLE_ENTITY,
        content={"error": "ValidationError", "fields": errors},
    )

Best Practices Implemented

Dependency Injection: FastAPI's dependency injection system is used for database sessions and current user retrieval, making testing easier.
Middleware: Custom logging middleware ensures we have visibility into every request.
Global Exception Handling: We catch SQLAlchemyError and generic Exception to prevent leaking internal server details to the client.

What's Next?

This project serves as a solid foundation. Future enhancements could include:

Redis Caching: To speed up product catalog reads.
Celery Tasks: For sending emails and processing payments asynchronously.
Elasticsearch: For advanced product search capabilities.

Conclusion

Building an e-commerce API with FastAPI is a rewarding experience. The framework's design encourages best practices while giving you the speed you need.

Check out the full code on GitHub github repo link and feel free to contribute!

Happy Coding✌️!