Cross-site scripting happens when a web application places untrusted content into a page without preserving the boundary between data and executable code. The browser runs the injected content with the authority of the affected site. The vulnerable path can be on the server, in client-side code, or across both.
Three paths to the browser
Stored cross-site scripting begins when the application saves content and later renders it for another request. Reflected cross-site scripting returns request data directly in a response. Client-side, or DOM-based, cross-site scripting occurs when browser code reads an untrusted value and sends it to an unsafe rendering operation.
An audit of vibe-coded software traces each source to the place where the browser uses it. The review includes obvious text fields as well as URLs, error messages, file names, integration data, rich-text content, and administrative screens.
| XSS path | Data source | Execution point |
|---|---|---|
| Stored | Database, upload, integration | Later page render |
| Reflected | Query, route, form request | Immediate server response |
| DOM-based | URL, storage, message event | Client-side rendering code |
| Mixed | Stored or reflected server data | Later client-side transformation |
Rendering context determines the control
The correct protection depends on where a value appears. HTML text, an attribute, a URL, CSS, and JavaScript are different parsing contexts. A transform that is safe for one context may be unsafe for another. Modern frameworks escape ordinary text by default, but explicit HTML rendering, template bypasses, rich-text plugins, and direct DOM operations can step outside that default.
Input validation still defines what the product accepts. Output encoding and safe rendering preserve the browser boundary even when accepted text contains punctuation or markup-like characters. When the product intentionally accepts HTML, sanitization must use a defined policy rather than a list of removed strings.
What the audit follows
The review treats cross-site scripting as a data-flow question:
- List untrusted sources: Include requests, storage, integrations, uploads, and browser messaging.
- Find rendering sinks: Inspect raw HTML APIs, template bypasses, script construction, and unsafe URL handling.
- Identify the context: Record how the browser will parse the value at that location.
- Verify the control: Check framework escaping, contextual encoding, or sanitization at the final boundary.
- Test the complete path: Exercise stored and client-side transformations, not only the first request.
Why generated interfaces need a full trace
A generated component may look safe because normal data produces normal markup. The weakness appears only when a value crosses a context the original prompt did not describe. Repeated helper code can also encode one screen correctly while another bypasses it for formatting.
The attack surface map shows every place content enters and renders. Tests then confirm that untrusted values remain data across the whole route. That evidence is part of the production review expected when software generated quickly becomes a maintained system.
