Skip to content

Security: ClementRingot/xsuaa-auth

Security

SECURITY.md

Security Policy

@arc-mcp/xsuaa-auth is an authentication library for Model Context Protocol servers: XSUAA / OAuth 2.0 + RFC 7591 Dynamic Client Registration + SAP BTP principal propagation. Because it sits on the authentication path, security reports are taken seriously — please follow this policy when reporting.

Supported Versions

Pre-1.0 (current state): only the latest published 0.x minor line receives security fixes. The API is still settling across the consuming MCP servers, so please track the latest release.

Version Supported
0.1.x
< 0.1 ❌ — please upgrade

After 1.0, this table will reflect the documented support window for each major.

Reporting a Vulnerability

Preferred — GitHub Private Vulnerability Reporting: Open a private advisory. This routes the report directly to the maintainers, keeps it confidential, and gives us a private workspace to coordinate the fix. (Private vulnerability reporting must be enabled in the repository Settings → Security → Advanced Security before this link works.)

Fallback — email: marianbsp@gmail.com. Please include "@arc-mcp/xsuaa-auth security" in the subject line. If you need to send encrypted email, request a public key in the first message.

Please do not open a public GitHub issue, post on the SAP Community, or share details on social media until a fix is published. Coordinated disclosure protects users running affected versions.

Response Times (best-effort, non-contractual)

Stage Target
Acknowledgement of report within 3 business days
Initial triage and severity assessment within 7 business days
Critical fix or mitigation within 14 days
High fix or mitigation within 30 days
Moderate fix or mitigation within 60 days
Low fix or mitigation best-effort

Severity follows CVSS v3.1 where applicable.

CVE Handling

Confirmed vulnerabilities receive a GitHub Security Advisory (GHSA) and, where applicable, a CVE assigned via GitHub's CNA. Patches publish through the normal release flow (release-please → npm via OIDC trusted publishing with provenance); the advisory marks affected versions and the fixed version. Where the patch warrants user action (for example a config change or a key/label rotation), the advisory and the release notes call it out explicitly.

Out of Scope

  • SAP system or XSUAA service vulnerabilities. This package is a client of XSUAA / the BTP Destination Service. Vulnerabilities in SAP BTP, XSUAA, the Cloud Connector, or the SAP backend itself belong to SAP — please report via SAP's responsible-disclosure channel.
  • Vulnerabilities in the MCP SDK, Express, jose, @sap/xssec, or other dependencies with no @arc-mcp/xsuaa-auth-specific exposure (i.e. the upstream advisory does not impact how this package uses the dependency). Please report upstream to the affected project; this package tracks affected upstream advisories via Dependabot.
  • Theoretical vulnerabilities without a concrete exploitation path against the package's documented usage. Design-hardening discussions are welcome in a regular GitHub issue, not the private advisory channel.
  • Misconfiguration in a consuming application — e.g. failing to set redirectUriPatterns in sync with the XSUAA xs-security.json, leaving required: false in production, or reusing the default dcrSigningSecret. The README documents the secure configuration; deployment hardening is the operator's responsibility.
  • Issues in unsupported versions (see Supported Versions above).

Safe Harbor

This project supports good-faith security research. Researchers acting in good faith and following this policy will not face legal action.

We commit to:

  • Responding within the timelines above.
  • Working with you to reproduce and understand the issue.
  • Crediting you in the resulting GHSA / CVE if you wish (or honoring an anonymous-disclosure request).
  • Not pursuing legal action against research conducted in accordance with this policy.

Security-relevant configuration

The package ships fail-closed defaults, but a few knobs are load-bearing for security and are documented in the README and docs/SPEC.md:

  • redirectUriPatterns / defaultRedirectUris must stay in sync with the XSUAA service's xs-security.json oauth2-configuration.redirect-uris. The /authorize redirect-URI shim is pattern-gated; a too-broad pattern weakens it.
  • dcrSigningSecret stabilizes DCR client_ids across restarts and should be a dedicated ≥32-byte secret. Rotating it (or bumping dcrKdfLabel / stateKdfLabel) is the revocation knob for issued client_ids and OAuth-state tokens.
  • createOidcVerifier({ algorithms }) defaults to ['RS256','ES256','PS256'] — an explicit allowlist that closes alg:none and algorithm-confusion. Do not widen it to include symmetric algorithms.
  • createOidcVerifier({ fallbackScopes }) defaults to [] (fail closed). When a verified OIDC token carries no accepted scope — no scope/scp claim, or claims that match none of acceptedScopes — the verifier grants fallbackScopes. The empty default means an IdP misconfigured to drop scope claims grants no privileges instead of silently falling back to read-only access. Only set fallbackScopes: ['read'] (or wider) if you deliberately want an unscoped-but-authenticated token to receive a baseline grant.
  • required: true on setupHttpAuth fails closed when no auth method is configured; leaving it false (the default) logs a loud warning and serves /mcp open.

Principal-propagation destination cache isolation

The per-user destination lookup (lookupDestinationWithUserToken in ./btp) resolves a PrincipalPropagation destination to a per-user credential (a SAML assertion or bearer token bound to the calling user's identity). To prevent one user's propagated identity from being served to another from a shared cache entry, the lookup pins the SAP Cloud SDK's isolationStrategy: 'tenant-user' on the cached getDestination() call. This is the SDK's default today, but pinning it explicitly keeps the per-user guarantee load-bearing in code: a future SDK default change — or accidentally reusing this path for a non-PP/technical destination — cannot silently widen the cache key to tenant-only and leak a propagated user identity across users. The startup (non-PP) resolver uses a direct fetch with no user-scoped cache, so it is unaffected.

There aren't any published security advisories