Skip to main content
Glama
Perufitlife

web-exposure-mcp

by Perufitlife
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

web-exposure-mcp

An MCP server that lets an AI agent point at a live deployed URL and confirm whether sensitive files are actually being served to the public — exposed .git, .env secrets, JavaScript source maps, backup/SQL dumps, directory listing, and dotfiles — by fetching the bytes and validating the content. Other tools give you a checklist of maybes; this reports only what is genuinely reachable, with evidence.

⚡ Run it in one line, no install, no API key:

npx web-exposure-mcp        # MCP server (stdio) for your AI client
npx -p web-exposure-mcp web-exposure-scan --url https://your-site.com   # one-shot CLI

🤝 Want it done for you? Fixed-scope external-exposure audit — $99 / 24h: I verify every finding live and send a written report with the exact fixes and which credentials to rotate.

npm downloads license node deps

$ npx -p web-exposure-mcp web-exposure-scan --url https://demo.example.com
2 critical, 2 high, 1 medium — 5 CONFIRMED via anonymous fetch (39 requests)
  CRITICAL  /.git/config   valid .git served — full source history downloadable
  CRITICAL  /.env          5 env vars served — API_KEY, DATABASE_URL, JWT_SECRET…
  HIGH      /main.js.map   valid source map — 142 original sources reconstructable
  HIGH      /backup.sql    SQL dump content served
  MEDIUM    /uploads/      directory listing enabled (Index of /uploads)

Why this exists

Publicly-served .git and .env files are routinely called one of the most common high-impact findings in external attack-surface management — Acunetix, Invicti and Legba all ship dedicated detections, and live HackerOne reports for exposed .git/.env are filed continuously. June 2026 saw record leaked-credential dumps, a large share sourced from live, misconfigured servers rather than breached databases.

The MCP ecosystem already covers SSL, CORS, security-headers, SEO audits, and code/commit secret scanning (GitHub MCP, GitGuardian) — but no MCP server probes a deployed URL for publicly-served secret files. This fills that gap: your agent can audit the live edge of any deployment, the way an attacker actually sees it.

The hard part isn't requesting /.env — it's avoiding false positives. Most modern sites answer 200 OK with index.html for every unknown path (SPA catch-all). web-exposure-mcp therefore reads the bytes and fingerprints the content (e.g. .git/config must parse as a git config, .env must contain KEY=VALUE secret lines, an archive must start with the real magic bytes) — so it flags facts, not guesses.

Related MCP server: aegis

Tools (MCP)

Tool

What it does

scan_web_exposure

Probe a live URL and return only the secret files genuinely served, with evidence. Args: url (required), only (optional check filter), timeout_ms.

list_exposure_checks

List every check id, severity and the paths it probes — feed ids into only.

What it confirms

Check id

Severity

Confirmed by

git_exposed

critical

/.git/config parses as a git config, or /.git/HEAD is a valid ref/sha

env_exposed

critical

dotenv served with ≥2 KEY=VALUE secret lines (not HTML)

source_map

high

.js.map parses as a source map with a sources[] array

backup_artifact

high

SQL-dump fingerprints, or ZIP/gzip magic bytes in the body

directory_listing

medium

the autoindex signature (Index of /…) is returned

dotfile_served

high

.htpasswd hashes, .npmrc/.netrc tokens, .aws/credentials, .ssh/id_rsa, .DS_Store, docker auth

Every check fires at most once and only when the served bytes prove it. Read-only: the scanner never writes anything to the target, follows no redirects into other hosts, and reads at most 64 KB per file (so it fingerprints a multi-GB backup without downloading it).

Add to your AI client

Claude Desktop / Cursor / any MCP client — add to your mcpServers config:

{
  "mcpServers": {
    "web-exposure": {
      "command": "npx",
      "args": ["-y", "web-exposure-mcp"]
    }
  }
}

Then ask your agent: “Scan https://staging.myapp.com for publicly exposed secret files.”

CLI usage

# Probe a live deployment
npx -p web-exposure-mcp web-exposure-scan --url https://your-site.com

# Run only specific checks
npx -p web-exposure-mcp web-exposure-scan --url https://your-site.com --only git_exposed,env_exposed

# Tighter per-request timeout
npx -p web-exposure-mcp web-exposure-scan --url https://your-site.com --timeout 8000

Output is JSON on stdout (pipe into CI) and a one-line summary on stderr.

Install (optional)

npm i -g web-exposure-mcp
web-exposure-mcp                       # start the MCP server (stdio)
web-exposure-scan --url https://site.com   # one-shot scan

Zero dependencies, pure Node ≥18. Every request goes straight from the tool to the target you name — nothing leaves your machine.

Sister tools

Same active-probe philosophy — confirm the real issue by fetching it, not by trusting a checklist. All MIT:

supabase-security · strapi-security · pocketbase-security · firebase-security · appwrite-security · nhost-security

License

MIT © Renzo Madueno

📚 Part of Awesome Backend Security Auditors — the full collection of keyless active-probe auditors.

Available Tools

2 tools
list_exposure_checksA

List every exposure check this server can run, with its id, severity, and the paths it probes. Use this to discover check ids for the only filter of scan_web_exposure.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; the description implicitly communicates a read-only listing operation but does not explicitly state non-destructive behavior or address authentication or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and output, no wasted words. Highly concise and structured effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of parameters and output schema, the description sufficiently covers what the tool does, what it returns, and when to use it, referencing the sibling tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so the description adds no parameter-specific info; baseline for 0 parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all exposure checks with id, severity, and paths, distinguishing it from the sibling tool scan_web_exposure by indicating its use for discovering check ids.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs the agent to use this tool to discover check ids for the 'only' filter of scan_web_exposure, providing clear context and prerequisite guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scan_web_exposureA

Probe a LIVE deployed URL and confirm which sensitive files/directories are actually publicly reachable — by fetching the bytes, not guessing. Detects exposed .git, .env secrets, JavaScript source maps, backup/SQL dumps & archives (.bak/.sql/.zip), directory listing, and sensitive dotfiles (.htpasswd/.npmrc/.aws/credentials/.ssh/id_rsa). Read-only: nothing is written to the target. Returns only findings that are genuinely served, with evidence.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe live base URL to scan, e.g. https://example.com (scheme optional, defaults to https).
onlyNoOptional: run only these check ids. Omit to run all.
timeout_msNoOptional per-request timeout in milliseconds (default 10000).

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explicitly states 'Read-only: nothing is written to the target' and emphasizes direct byte-fetching rather than guessing. However, it does not discuss rate limits, authentication needs, or potential impact on target, which would be beneficial given no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, front-loaded with the core purpose, lists specific checks, and includes a brief read-only note. Every sentence adds value, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's function, checks performed, and output nature (genuine findings with evidence). Given the absence of an output schema, it provides adequate context, though it could further detail the output structure or non-functional aspects like parallelism.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes all parameters. The description adds no additional insight over the schema, such as format constraints or usage tips, so it meets the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool probes a live URL to confirm sensitive exposures, listing specific file types. It differentiates from sibling 'list_exposure_checks' which likely lists available checks rather than performing scans.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (for active scanning) but does not explicitly contrast with alternatives or state when not to use it. Sibling tool 'list_exposure_checks' is mentioned but no direct guidance on switching between them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedlist_exposure_checks
    • First observedscan_web_exposure
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are entirely distinct: one lists available checks, the other runs the scan. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools follow the consistent verb_noun pattern (list_exposure_checks, scan_web_exposure), making their purpose immediately clear.

Tool Count4/5

With only two tools, the server is minimal but well-scoped. Each tool serves a clear function; no superfluous or missing core operations.

Completeness5/5

The tool set covers the full workflow: discover available checks, then run a targeted scan. No obvious gaps for the stated purpose of checking web exposure.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • meok-mcp-injection-scan-mcp

    CSOAI-ORG
    A
    license
    A
    quality
    D
    maintenance
    Scans MCP servers for prompt-injection, tool-poisoning, and SSRF vulnerabilities using 30+ canonical rules across 5 severity tiers, with optional signed safety reports for procurement.
    5
    MIT

  • InjectShield

    bch1212
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server that provides tools to scan text and URLs for prompt injection attacks, protecting AI agents from adversarial inputs.
    MIT

  • VulnPilot

    arojit
    A
    license
    A
    quality
    B
    maintenance
    An MCP server that gives AI assistants the ability to check open-source packages for vulnerabilities, enrich findings with real-world exploit intelligence, and statically analyse whether vulnerable code is actually reachable in your project.
    3
    1
    Apache 2.0