Summary
swagger-typescript-api forwarded a supplied authorization token header to every URL used when resolving remote OpenAPI references.
When a malicious or compromised OpenAPI specification includes attacker-controlled external $ref URLs, this behavior can leak CI or developer bearer tokens to cross-origin endpoints, exposing sensitive credentials during client generation.
swagger-typescript-api forwarded a supplied authorization token header to every URL used when resolving remote OpenAPI references.
When a malicious or compromised OpenAPI specification includes attacker-controlled external $ref URLs, this behavior can leak CI or developer bearer tokens to cross-origin endpoints, exposing sensitive credentials during client generation.
Affected context
This vulnerability occurs in workflows where swagger-typescript-api is used to generate TypeScript API clients from OpenAPI specifications and the --authorizationToken (or equivalent) option is provided.
It is most relevant when:
- OpenAPI specs reference external documents via
$refURLs - Those URLs are not strictly controlled or validated
- The token represents sensitive CI/CD or developer credentials used to fetch protected schemas
In such setups, a malicious or untrusted spec can cause the generator to contact arbitrary remote endpoints while including the bearer token.
This vulnerability occurs in workflows where swagger-typescript-api is used to generate TypeScript API clients from OpenAPI specifications and the --authorizationToken (or equivalent) option is provided.
It is most relevant when:
- OpenAPI specs reference external documents via
$refURLs - Those URLs are not strictly controlled or validated
- The token represents sensitive CI/CD or developer credentials used to fetch protected schemas
In such setups, a malicious or untrusted spec can cause the generator to contact arbitrary remote endpoints while including the bearer token.
Exploit preconditions
- Attack surface: swagger-typescript-api invocation in developer machines or CI pipelines.
- Required access: Ability to supply or modify the OpenAPI spec consumed by the generator (e.g., via a compromised spec file, remote schema URL, or untrusted third-party spec).
- Trigger point: Execution of swagger-typescript-api with an authorization token while
warmUpRemoteSchemasCacheresolves external$refURLs throughfetchRemoteSchemaDocument. - Why exploitation is possible: The implementation forwards the same authorization header to all remote schema fetches without scoping it to the intended origin, allowing attacker-controlled endpoints embedded in
$refto receive the bearer token.
- Attack surface: swagger-typescript-api invocation in developer machines or CI pipelines.
- Required access: Ability to supply or modify the OpenAPI spec consumed by the generator (e.g., via a compromised spec file, remote schema URL, or untrusted third-party spec).
- Trigger point: Execution of swagger-typescript-api with an authorization token while
warmUpRemoteSchemasCacheresolves external$refURLs throughfetchRemoteSchemaDocument. - Why exploitation is possible: The implementation forwards the same authorization header to all remote schema fetches without scoping it to the intended origin, allowing attacker-controlled endpoints embedded in
$refto receive the bearer token.
Why this happens
The underlying bug class is sensitive information exposure caused by improper handling and propagation of authentication headers during remote resource resolution.
In swagger-typescript-api, getRemoteRequestHeaders forwards the --authorizationToken value to every URL fetched when resolving remote schema documents, regardless of origin or trust level.
This maps to CWE-200: Exposure of Sensitive Information and CWE-918: Server-Side Request Forgery patterns, where internal credentials are sent to attacker-chosen endpoints.
Conceptually, the insecure pattern is treating an authorization token as a general-purpose header for all outgoing HTTP requests instead of constraining it to the specific trusted host or using a distinct, scoped credential.
The underlying bug class is sensitive information exposure caused by improper handling and propagation of authentication headers during remote resource resolution.
In swagger-typescript-api, getRemoteRequestHeaders forwards the --authorizationToken value to every URL fetched when resolving remote schema documents, regardless of origin or trust level.
This maps to CWE-200: Exposure of Sensitive Information and CWE-918: Server-Side Request Forgery patterns, where internal credentials are sent to attacker-chosen endpoints.
Conceptually, the insecure pattern is treating an authorization token as a general-purpose header for all outgoing HTTP requests instead of constraining it to the specific trusted host or using a distinct, scoped credential.
Potential impact
- Attackers may obtain CI/CD bearer tokens or developer access tokens.
- Compromised tokens could allow unauthorized access to private repositories, registries, or build artifacts.
- Attackers can potentially modify build outputs, tamper with generated client code, or alter deployment configurations.
- Subsequent lateral movement within development or production environments can occur if the leaked token has broad permissions.
- Long-lived or highly privileged tokens can be reused for persistent unauthorized access until revoked.
- Attackers may obtain CI/CD bearer tokens or developer access tokens.
- Compromised tokens could allow unauthorized access to private repositories, registries, or build artifacts.
- Attackers can potentially modify build outputs, tamper with generated client code, or alter deployment configurations.
- Subsequent lateral movement within development or production environments can occur if the leaked token has broad permissions.
- Long-lived or highly privileged tokens can be reused for persistent unauthorized access until revoked.
General mitigation guidance
Effective mitigation focuses on limiting where and how sensitive headers are propagated and reducing trust in external schema references.
Common defensive patterns include:
- Scoping authorization tokens to specific, trusted origins rather than attaching them to all remote requests.
- Separating credentials used to fetch protected schemas from general HTTP traffic, using distinct configuration with strict host allowlists.
- Treating external
$refURLs as untrusted input and validating or restricting them through explicit allowlists or domain filters. - Using non-sensitive, short-lived tokens or anonymized access mechanisms for schema retrieval when possible.
- Ensuring generators and tooling are configured with least-privilege credentials and minimal network exposure.
- Building secure-by-default wrappers that strip or override headers for cross-origin or non-allowlisted requests.
Effective mitigation focuses on limiting where and how sensitive headers are propagated and reducing trust in external schema references.
Common defensive patterns include:
- Scoping authorization tokens to specific, trusted origins rather than attaching them to all remote requests.
- Separating credentials used to fetch protected schemas from general HTTP traffic, using distinct configuration with strict host allowlists.
- Treating external
$refURLs as untrusted input and validating or restricting them through explicit allowlists or domain filters. - Using non-sensitive, short-lived tokens or anonymized access mechanisms for schema retrieval when possible.
- Ensuring generators and tooling are configured with least-privilege credentials and minimal network exposure.
- Building secure-by-default wrappers that strip or override headers for cross-origin or non-allowlisted requests.
How teams detect issues like this
Organizations can detect similar issues by:
- Reviewing tool configurations and build scripts for patterns where authorization headers or tokens are forwarded to arbitrary URLs without origin checks.
- Implementing static analysis or policy-as-code checks (e.g., in CI) that flag use of broad authorization options on generators, linters, or documentation tools that perform remote HTTP requests.
- Auditing OpenAPI specifications for external
$refURLs pointing to unexpected domains, especially in third-party or vendor-supplied specs. - Using HTTP proxy logs or egress monitoring to identify sensitive headers being sent to non-trusted hosts during build or generation phases.
- Employing automated code and configuration review tools that highlight cross-origin requests carrying authentication headers or secrets.
Organizations can detect similar issues by:
- Reviewing tool configurations and build scripts for patterns where authorization headers or tokens are forwarded to arbitrary URLs without origin checks.
- Implementing static analysis or policy-as-code checks (e.g., in CI) that flag use of broad authorization options on generators, linters, or documentation tools that perform remote HTTP requests.
- Auditing OpenAPI specifications for external
$refURLs pointing to unexpected domains, especially in third-party or vendor-supplied specs. - Using HTTP proxy logs or egress monitoring to identify sensitive headers being sent to non-trusted hosts during build or generation phases.
- Employing automated code and configuration review tools that highlight cross-origin requests carrying authentication headers or secrets.
