By Garrett Kohlrusch | GK Data LLC
A comment entered in a mobile app should not become executable code when someone opens the corresponding web page. That cross-surface failure was the core of a stored cross-site scripting vulnerability I reported through the NASA Vulnerability Disclosure Program.
The public Bugcrowd disclosure records the issue as P2 priority, disclosed by GK Data, and resolved after acceptance and remediation. This case study focuses on the data flow and defensive lessons. It does not republish the exploit payload.
Verified disclosure facts
- Program: NASA Vulnerability Disclosure Program
- Affected workflow: publicly shared GLOBE Observer observation comments
- Priority: P2 under Bugcrowd’s VRT rating
- Disclosure date: December 30, 2025
- Status: resolved and fixed
The mobile-to-web execution path
The input originated in the GLOBE Observer mobile experience. A user could create an observation, add a comment, and share it publicly. The same observation was then available through a browser-based public page.
The mobile app accepted the comment as data. The problem appeared later, when the public web renderer treated that stored value as HTML capable of executing JavaScript. A visitor did not need to edit the observation or interact with the comment. Loading the affected shared page was enough to reach the vulnerable rendering context.
That distinction matters. The finding was not “JavaScript running in a mobile app.” It was untrusted content crossing from a mobile input surface into an unsafe web output sink.
What I manually validated
Testing stayed within the authorized program and used a controlled callback. I confirmed that:
- the comment survived storage and appeared on the public observation page;
- the browser interpreted the stored value as active HTML rather than plain text;
- JavaScript executed when another browser session loaded the affected page; and
- the execution context could initiate an outbound request containing script-readable cookie data.
The public report describes the potential for cookie theft and session compromise. The exact account impact depends on the application’s session design: whether a reusable authentication value is accessible to JavaScript, whether it remains valid when replayed, and what privileges the affected viewer holds. The confirmed security boundary failure was persistent JavaScript execution in the browser of a visitor who opened the shared observation.
Root cause
The application failed to preserve the comment as data at the final rendering step. Input validation can improve data quality, but it is not a reliable substitute for context-appropriate output handling. If comments are intended to be plain text, the renderer should use a text-only sink. If limited markup is a real product requirement, the allowed HTML must be sanitized with a maintained library before it reaches the DOM.
This is why testing only the form visible in a browser can miss important risk. The source of a value and the place where it becomes dangerous may live in different clients, services, or teams.
Remediation priorities
- Render comments as text by default. Do not place untrusted strings into an HTML sink when no markup is required.
- Sanitize intentional HTML. Use a maintained, context-aware sanitizer and avoid modifying sanitized output before insertion.
- Map every rendering surface. Test mobile, web, administrative, moderation, export, and notification views that consume the same stored field.
- Reduce impact in depth. Use appropriate cookie attributes and a restrictive Content Security Policy. These controls can limit consequences, but they do not repair unsafe rendering.
- Add regression coverage. Include representative hostile strings in tests for every component that renders user-generated content.
The broader testing lesson
Modern applications rarely have a single input and a single output. A value entered on a phone may later appear in a public profile, a staff dashboard, an email, a PDF, or an internal review queue. Security testing has to follow that value across the complete workflow.
That is also why GK Data combines AI-assisted reconnaissance and documentation with manual validation. Automation can help map surfaces and organize evidence. A person still has to reproduce the behavior, confirm the execution context, define the affected user, and separate demonstrated impact from possible impact.
For the defensive standard behind the remediation above, see the OWASP Cross Site Scripting Prevention Cheat Sheet. To discuss a similar cross-client workflow, visit Web Application and API Penetration Testing or contact GK Data.