Summary
swagger-typescript-api templates can embed unescaped OpenAPI server URLs directly into generated Axios HttpClient constructors, enabling code injection.
When developers consume attacker-controlled or untrusted OpenAPI specifications, the resulting generated client code may execute arbitrary JavaScript at construction time.
swagger-typescript-api templates can embed unescaped OpenAPI server URLs directly into generated Axios HttpClient constructors, enabling code injection.
When developers consume attacker-controlled or untrusted OpenAPI specifications, the resulting generated client code may execute arbitrary JavaScript at construction time.
Affected context
This vulnerability appears in projects that use swagger-typescript-api to generate TypeScript clients from OpenAPI documents, specifically when:
- The Axios-based HTTP client template is selected or used by default
- OpenAPI
servers[0].urlvalues are taken directly from untrusted or externally supplied specifications - Generated code is compiled and executed without reviewing or sanitizing the interpolated server URL
It is most relevant in environments where OpenAPI specs can be influenced by third parties, such as shared API registries, dynamic spec generation, or multi-tenant documentation systems.
This vulnerability appears in projects that use swagger-typescript-api to generate TypeScript clients from OpenAPI documents, specifically when:
- The Axios-based HTTP client template is selected or used by default
- OpenAPI
servers[0].urlvalues are taken directly from untrusted or externally supplied specifications - Generated code is compiled and executed without reviewing or sanitizing the interpolated server URL
It is most relevant in environments where OpenAPI specs can be influenced by third parties, such as shared API registries, dynamic spec generation, or multi-tenant documentation systems.
Exploit preconditions
- Attack surface: The code generation pipeline that consumes OpenAPI specifications.
- Required access: Ability to provide or modify an OpenAPI spec used by swagger-typescript-api (e.g., control over
servers[0].url). - Trigger point: Construction of a generated
HttpClientorApiinstance in application code, which executes the injected JavaScript. - Why exploitation is possible: The Axios HttpClient EJS template interpolates
servers[0].urldirectly into TypeScript source without escaping or validation, allowing malicious content to break out of string context and inject executable code.
- Attack surface: The code generation pipeline that consumes OpenAPI specifications.
- Required access: Ability to provide or modify an OpenAPI spec used by swagger-typescript-api (e.g., control over
servers[0].url). - Trigger point: Construction of a generated
HttpClientorApiinstance in application code, which executes the injected JavaScript. - Why exploitation is possible: The Axios HttpClient EJS template interpolates
servers[0].urldirectly into TypeScript source without escaping or validation, allowing malicious content to break out of string context and inject executable code.
Why this happens
The underlying bug stems from treating data originating from an OpenAPI document as trusted code in a template-driven generation process.
In the vulnerable Axios client template, servers[0].url is interpolated without escaping or confinement to a safe literal string, enabling crafted values to alter the generated TypeScript syntax and inject arbitrary JavaScript.
This pattern maps to CWE-94 (Improper Control of Generation of Code), combined with CWE-74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component) and CWE-1336 (Improper Neutralization of Script-Related HTML Tags in a Web Page), because spec fields are not neutralized before being embedded in source code that will later be executed.
The underlying bug stems from treating data originating from an OpenAPI document as trusted code in a template-driven generation process.
In the vulnerable Axios client template, servers[0].url is interpolated without escaping or confinement to a safe literal string, enabling crafted values to alter the generated TypeScript syntax and inject arbitrary JavaScript.
This pattern maps to CWE-94 (Improper Control of Generation of Code), combined with CWE-74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component) and CWE-1336 (Improper Neutralization of Script-Related HTML Tags in a Web Page), because spec fields are not neutralized before being embedded in source code that will later be executed.
Potential impact
- Generated clients may execute attacker-controlled JavaScript during object construction.
- Attackers could access or exfiltrate sensitive data handled by the client, such as tokens or headers.
- Malicious code can tamper with outgoing requests, altering endpoints, parameters, or authentication behavior.
- The broader application runtime may be compromised if generated clients run in privileged or trusted contexts.
- Generated clients may execute attacker-controlled JavaScript during object construction.
- Attackers could access or exfiltrate sensitive data handled by the client, such as tokens or headers.
- Malicious code can tamper with outgoing requests, altering endpoints, parameters, or authentication behavior.
- The broader application runtime may be compromised if generated clients run in privileged or trusted contexts.
General mitigation guidance
Effective mitigation focuses on treating specification-derived values as untrusted input and preventing them from becoming executable code.
General defensive patterns include:
- Escaping or safely encoding all OpenAPI fields before interpolating into templates so they remain data within string literals.
- Constraining
serversconfiguration to validated, well-formed URLs from trusted sources rather than arbitrary spec content. - Separating configuration data (such as base URLs) from generated code by providing them at runtime via environment variables or strongly typed configuration objects.
- Applying least privilege principles to any code that consumes generated clients, so a compromised client has limited impact.
- Designing templates so that dynamic fields cannot alter the surrounding syntax or introduce new statements, for example by using strict string concatenation and avoiding direct raw insertion into executable contexts.
Effective mitigation focuses on treating specification-derived values as untrusted input and preventing them from becoming executable code.
General defensive patterns include:
- Escaping or safely encoding all OpenAPI fields before interpolating into templates so they remain data within string literals.
- Constraining
serversconfiguration to validated, well-formed URLs from trusted sources rather than arbitrary spec content. - Separating configuration data (such as base URLs) from generated code by providing them at runtime via environment variables or strongly typed configuration objects.
- Applying least privilege principles to any code that consumes generated clients, so a compromised client has limited impact.
- Designing templates so that dynamic fields cannot alter the surrounding syntax or introduce new statements, for example by using strict string concatenation and avoiding direct raw insertion into executable contexts.
How teams detect issues like this
Organizations can identify similar vulnerabilities through:
- Static analysis rules that flag direct template interpolation of untrusted inputs into executable code segments or constructors.
- Code review practices focused on code-generation templates, ensuring that external specification fields are always escaped or validated.
- Build-time checks that scan generated sources for unexpected tokens, statements, or non-URL content where only configuration values should appear.
- Policy-based controls requiring that OpenAPI documents used for generation originate from vetted repositories and pass schema, format, and sanitation checks before use.
- Integrating automated code review tools to inspect both templates and generated output for code injection patterns.
Organizations can identify similar vulnerabilities through:
- Static analysis rules that flag direct template interpolation of untrusted inputs into executable code segments or constructors.
- Code review practices focused on code-generation templates, ensuring that external specification fields are always escaped or validated.
- Build-time checks that scan generated sources for unexpected tokens, statements, or non-URL content where only configuration values should appear.
- Policy-based controls requiring that OpenAPI documents used for generation originate from vetted repositories and pass schema, format, and sanitation checks before use.
- Integrating automated code review tools to inspect both templates and generated output for code injection patterns.
