MCP server Reporting API security — CSP violation reports, Report-To endpoint privacy leaks, report flooding DoS, and Network Error Logging (NEL) topology disclosure

How the Reporting API works

The Report-To header (Reporting API v0) and its successor Reporting-Endpoints header (Reporting API v1) configure named collector endpoints that the browser sends reports to. Reports are batched and sent asynchronously — the browser queues them and delivers them in bulk, even after the page is closed (via keepalive). Configured endpoints persist for the header's max_age duration — up to 604800 seconds (7 days) — which means a single page load can configure reporting that persists across all subsequent visits to the origin during that window.

# Reporting API v0 (Report-To header)
Report-To: {"group":"csp-endpoint","max_age":86400,
  "endpoints":[{"url":"https://reporting.example.com/collect"}]}
Content-Security-Policy: default-src 'self'; report-to csp-endpoint

# Reporting API v1 (Reporting-Endpoints header — Chrome 96+)
Reporting-Endpoints: csp-endpoint="https://reporting.example.com/collect"
Content-Security-Policy: default-src 'self'; report-to csp-endpoint

Reports are sent as application/reports+json POST requests with structured JSON bodies that include the report type, URL where the violation occurred, user agent, timestamp, and violation-specific details.

CSP violation report privacy leaks

A CSP violation report contains the blocked-uri field (the URL of the resource that was blocked) and the document-uri field (the URL of the page where the violation occurred). If the MCP client uses query parameters or URL fragments to carry sensitive state (e.g., https://mcp-client.example.com/chat?session=abc123&user=42), this URL appears in violation reports sent to the collector.

If the collector is a third-party service (Sentry, Report URI, Cronitor), this means the third party receives session IDs, user IDs, and other sensitive URL parameters from every CSP violation on the MCP client. For MCP clients where tool output often contains URLs processed as part of tasks (e.g., the user asks the agent to "summarize this document" and pastes a private URL), those URLs may appear in violation reports if the MCP client CSP is misconfigured to trigger violations on user-pasted content.

report-uri vs report-to: migration compatibility gap

Firefox does not fully support report-to as of 2026 — violations go unreported in Firefox when report-uri is not present. Sites that migrate entirely to report-to lose Firefox violation visibility. The correct migration pattern is to include both directives during a transition period: report-uri /fallback; report-to csp-endpoint. Browsers that support report-to prefer it; others fall back to report-uri.

Report flooding from MCP tool output

An MCP tool that returns HTML or JavaScript that intentionally triggers CSP violations can generate large numbers of violation reports. With report-uri (unbatched), each violation generates an immediate POST request to the collector. Tool output that generates 1000 violations per second — easily achievable with a loop that attempts to load 1000 blocked resources — can overwhelm a reporting collector, causing legitimate violation reports to be dropped or delayed.

<!-- Tool output that floods the CSP reporter (requires no JS execution) -->
<!-- Each img src triggers a CSP violation report if img-src is restricted -->
<img src="https://blocked-1.example.com/x.png">
<img src="https://blocked-2.example.com/x.png">
<!-- ... repeat 10,000 times ... -->

This is a DoS against the monitoring infrastructure, not the MCP server itself. In practice, rate-limiting at the collector (standard for services like Report URI) mitigates the impact, but a self-hosted collector with no rate limiting is vulnerable. Additionally, the flood can mask real violations that get dropped during the flood.

Network Error Logging (NEL) topology disclosure

NEL configures the browser to report network errors (DNS failures, TCP connection failures, TLS errors) when fetching resources. For MCP servers that proxy requests to internal APIs and return those URLs in tool output for the client to fetch, NEL reports sent to a third-party collector can reveal the internal hostnames and IP addresses of those APIs.

# NEL header exposes internal topology to the NEL collector
NEL: {"report_to":"default","max_age":86400,"include_subdomains":false}
Report-To: {"group":"default","max_age":86400,
  "endpoints":[{"url":"https://third-party-nel-collector.com/"}]}

# If the MCP client fetches https://internal-api.corp.skillaudit.dev/data
# and that fetch fails, the NEL report includes:
# { "type": "network-error", "url": "https://internal-api.corp.skillaudit.dev/data", ... }
# This goes to third-party-nel-collector.com — disclosing the internal hostname

The fix is to use a first-party NEL collector — a same-origin endpoint that the MCP server controls — rather than a third-party service. Internal hostnames never leave the organization.

SkillAudit findings for Reporting API

Run a SkillAudit scan on your MCP server to audit Reporting API endpoint configuration, detect third-party collector data flows, and identify rate-limiting gaps that enable report flooding from tool output.