T09 · Insecure Skill Coding Practices
- Location
references/react-spa.md:69- Finding
Bearer Token Can Be Sent to an Unrestricted Network Destination
- Content
View full analysis
Vulnerability Details
File Location:
references/react-spa.md, lines 69–75
Vulnerability Type: Unrestricted bearer-token destination
Risk Level: HighVulnerable Code
typescript export async function apiFetch(auth: { user?: { access_token?: string } }, input: string) { return fetch(input, { headers: auth.user?.access_token ? { Authorization: `Bearer ${auth.user.access_token}` } : undefined, }); }Technical Analysis
The documented API helper accepts an unrestricted string as its request destination and automatically adds the current OIDC access token as an
Authorizationbearer credential. It does not require a relative API path, constrain requests to a configured first-party API origin, validate the destination against an allowlist, or reject unsafe schemes and untrusted hosts.Attaching an access token to requests sent to the application's trusted API is necessary for the Skill's declared OIDC functionality. Allowing that credential to be attached to an arbitrary caller-provided destination exceeds the minimum network privilege necessary.
If an application adopts this example and any attacker-controlled value can reach
input, the helper can transmit the token to an attacker-controlled endpoint. Although browser CORS rules can restrict access to responses, they do not generally prevent the outbound authenticated request or the receiving server from observing itsAuthorizationheader.Attack Path
- A developer adopts the documented
apiFetchhelper in a React or TypeScript SPA. - A URL derived from untrusted input, compromised application state, a malicious link, or another attacker-influenced source is passed to
input. - The attacker supplies a destination such as
https://attacker.example/collect. - The helper adds
Authorization: Bearer <access_token>and sends the request to that destination. - The attacker-controlled server record ...[truncated 864 chars]
- A developer adopts the documented
- Remediation
View remediation
Remediation Suggestions
Replace the unrestricted authenticated fetch helper with one bound to an explicitly configured and trusted API origin:
- Accept relative API paths rather than arbitrary absolute URLs.
- Resolve each path against a fixed
VITE_API_BASE_URL. - Verify that the resolved URL's origin exactly matches the configured API origin before adding the bearer token.
- Require HTTPS for non-development deployments.
- Keep authenticated API requests separate from a generic unauthenticated fetch helper.
- Avoid accepting redirect modes or request options that could forward credentials unexpectedly.
- Continue enforcing issuer, audience, scope, and expiry checks at the resource server; client-side destination checks are defense in depth and do not replace server-side validation.
Example hardened pattern:
typescript const apiBaseUrl = new URL(import.meta.env.VITE_API_BASE_URL); export async function apiFetch( auth: { user?: { access_token?: string } }, path: string, ) { const url = new URL(path, apiBaseUrl); if (url.origin !== apiBaseUrl.origin) { throw new Error('Refusing to send credentials to an untrusted origin'); } if (import.meta.env.PROD && url.protocol !== 'https:') { throw new Error('Authenticated API requests must use HTTPS'); } return fetch(url, { headers: auth.user?.access_token ? { Authorization: `Bearer ${auth.user.access_token}` } : undefined, redirect: 'error', }); }For stricter enforcement, reject absolute input altogether and permit only paths beginning with
/. Document that authenticated requests must only target the configured resource server.