Summary
Generated JHipster applications may store attacker-controlled Blob data together with a user-supplied ContentType and later render it through a generated file-opening helper. If an authenticated user with write access stores active HTML or SVG content, a privileged user who opens it may trigger script execution under the application origin, depending on browser behavior and content security policy.
Generated JHipster applications may store attacker-controlled Blob data together with a user-supplied ContentType and later render it through a generated file-opening helper. If an authenticated user with write access stores active HTML or SVG content, a privileged user who opens it may trigger script execution under the application origin, depending on browser behavior and content security policy.
Affected context
The issue occurs in generated JHipster applications that:
- Include entities capable of storing Blob data
- Persist and return attacker-controlled Blob content and ContentType values
- Use the generated
openFilehelper to create browser object URLs - Permit a lower-privileged authenticated user to write content later viewed by another user
Exploitability is influenced by the application's content security policy, browser handling of Blob URLs, and whether active HTML or SVG content is rendered.
The issue occurs in generated JHipster applications that:
- Include entities capable of storing Blob data
- Persist and return attacker-controlled Blob content and ContentType values
- Use the generated
openFilehelper to create browser object URLs - Permit a lower-privileged authenticated user to write content later viewed by another user
Exploitability is influenced by the application's content security policy, browser handling of Blob URLs, and whether active HTML or SVG content is rendered.
Exploit preconditions
- Attack surface: Generated web application REST endpoints and client-side Blob handling
- Required access: An authenticated account with write access to a Blob-bearing entity
- Trigger point: A user, potentially with higher privileges, opens the stored Blob through the generated file-viewing workflow
- Why exploitation is possible: The application trusts attacker-controlled ContentType metadata and uses it as the Blob MIME type before opening an object URL, allowing active content to be interpreted by the browser
- Attack surface: Generated web application REST endpoints and client-side Blob handling
- Required access: An authenticated account with write access to a Blob-bearing entity
- Trigger point: A user, potentially with higher privileges, opens the stored Blob through the generated file-viewing workflow
- Why exploitation is possible: The application trusts attacker-controlled ContentType metadata and uses it as the Blob MIME type before opening an object URL, allowing active content to be interpreted by the browser
Why this happens
The underlying flaw is insufficient output and content-type validation for attacker-controlled Blob data. The generated client helper passes a persisted ContentType directly to the browser Blob API and opens the resulting object URL without reliably restricting active formats such as HTML or SVG.
This maps to CWE-79: Improper Neutralization of Input During Web Page Generation, because stored attacker-controlled content can be interpreted as executable web content when rendered in a user's browser. The insecure pattern combines trusted rendering behavior with untrusted media type and content metadata.
The underlying flaw is insufficient output and content-type validation for attacker-controlled Blob data. The generated client helper passes a persisted ContentType directly to the browser Blob API and opens the resulting object URL without reliably restricting active formats such as HTML or SVG.
This maps to CWE-79: Improper Neutralization of Input During Web Page Generation, because stored attacker-controlled content can be interpreted as executable web content when rendered in a user's browser. The insecure pattern combines trusted rendering behavior with untrusted media type and content metadata.
Potential impact
- JavaScript may execute in the application's origin when a victim opens the content
- An attacker could access data exposed to the victim's browser session
- User actions could be performed in the victim's context
- Sensitive application information could be disclosed
- The application could be used for phishing or persistent user-interface manipulation
- JavaScript may execute in the application's origin when a victim opens the content
- An attacker could access data exposed to the victim's browser session
- User actions could be performed in the victim's context
- Sensitive application information could be disclosed
- The application could be used for phishing or persistent user-interface manipulation
General mitigation guidance
Mitigation generally focuses on treating uploaded content and its metadata as untrusted.
Common defensive patterns include:
- Allowing only an explicit, narrow set of non-active MIME types for stored files
- Deriving content types from validated file signatures or server-side policy rather than trusting client input
- Serving user-controlled files through an isolated origin or download-only response path
- Preventing inline rendering of HTML, SVG, and other active formats unless they are sanitized and intentionally supported
- Applying restrictive Content Security Policy and related browser isolation controls
- Enforcing authorization checks for both Blob writes and reads
- Limiting privileged data exposure and running the application with least-privilege access
Mitigation generally focuses on treating uploaded content and its metadata as untrusted.
Common defensive patterns include:
- Allowing only an explicit, narrow set of non-active MIME types for stored files
- Deriving content types from validated file signatures or server-side policy rather than trusting client input
- Serving user-controlled files through an isolated origin or download-only response path
- Preventing inline rendering of HTML, SVG, and other active formats unless they are sanitized and intentionally supported
- Applying restrictive Content Security Policy and related browser isolation controls
- Enforcing authorization checks for both Blob writes and reads
- Limiting privileged data exposure and running the application with least-privilege access
How teams detect issues like this
Detection can include:
- Static analysis for Blob constructors or object URL creation using request- or database-derived MIME types
- Code review checks for client-controlled ContentType values reaching rendering or navigation APIs
- Tests that attempt to store active HTML or SVG content and verify it is downloaded, rejected, or safely isolated
- Policy checks requiring allowlisted media types and server-side validation for file uploads
- Monitoring for unusual uploads, repeated ContentType changes, and access to stored active-content resources
Automated security review tools may help identify data flows from REST responses into browser rendering APIs.
Detection can include:
- Static analysis for Blob constructors or object URL creation using request- or database-derived MIME types
- Code review checks for client-controlled ContentType values reaching rendering or navigation APIs
- Tests that attempt to store active HTML or SVG content and verify it is downloaded, rejected, or safely isolated
- Policy checks requiring allowlisted media types and server-side validation for file uploads
- Monitoring for unusual uploads, repeated ContentType changes, and access to stored active-content resources
Automated security review tools may help identify data flows from REST responses into browser rendering APIs.
