What Cross-Site Scripting taught me about sources, sinks, contexts and safe rendering.
After authentication and access control, the next vulnerability felt especially close to my frontend background: Cross-Site Scripting.
At first, XSS can look like a simple payload exercise.
You put some input into a field, the browser executes JavaScript, and the lab is solved.
But after spending more time with reflected, stored and DOM-based XSS, I realised that the real lesson is not about alert boxes.
The real lesson is about how data moves through an application and how the browser interprets it.
As a Frontend Engineer, this topic felt different because I already work with forms, components, rendering, attributes, user input, API responses and DOM updates almost every day.
Learning XSS made me look at those same things from a security perspective.
Not only:
<pre><code>Does this render correctly?
</code></pre>
but also:
<pre><code>Is this data being interpreted safely?
</code></pre>
<h2>What XSS Actually Means</h2>
Cross-Site Scripting happens when user-controlled data is placed into a page in a way that the browser treats as code instead of data.
That is the key idea.
The dangerous part is not just that a user can type something into a form. The dangerous part is what the application does with that input later.
For example:
<pre><code>User input -&gt; server response -&gt; HTML page -&gt; browser interpretation
</code></pre>
or:
<pre><code>URL parameter -&gt; JavaScript -&gt; DOM update -&gt; executable context
</code></pre>
If the application does not handle the data safely, the browser may execute it as JavaScript.
That can lead to different impacts depending on the application, such as performing actions as the user, reading sensitive data available in the page, stealing non-HttpOnly tokens, modifying page content, redirecting users, or attacking other users of the application.
The exact impact depends on where the vulnerability appears and what the application allows the attacker to do.
<h2>Reflected, Stored and DOM-Based XSS</h2>
<img src="https://media.daily.dev/image/upload/s--yNosnBud--/f_auto/v1779360809/ugc/content_6f3468aa-0b6a-4402-97e4-59cfd38e5594?_a=BAMAMiWQ0" alt="5876ba19-6a29-4cf9-9675-f642297fd16d.png">
Reflected XSS helped me understand how request input can come straight back in the response.
Stored XSS showed why saved user content is more dangerous, because one unsafe value can affect many users later.
DOM-based XSS felt closest to frontend development, because the vulnerable flow often happens entirely in client-side JavaScript.
The issue is not only the input itself.
The issue is where the input goes.
<h2>The Real Lesson: Sources, Sinks and Contexts</h2>
One of the most useful concepts I learned was the idea of sources and sinks.
A source is where untrusted data comes from.
For example:
<pre><code>URL parameters
location.search
location.hash
form input
API responses
stored user content
cookies
localStorage
</code></pre>
A sink is where that data ends up.
Some sinks are safe. Some are dangerous.
For example, rendering a value as plain text is very different from inserting it as HTML.
That distinction matters.
The same input can be safe in one context and dangerous in another.
For example:
<pre><code>HTML body context
HTML attribute context
JavaScript context
URL context
DOM update context
</code></pre>
This was one of the biggest mindset changes for me.
Before learning XSS properly, it is easy to think:
<pre><code>This input is dangerous.
</code></pre>
But a better way to think is:
<pre><code>Where does this input go?
How is it encoded?
What context is it rendered into?
Will the browser treat it as text, HTML, an attribute, a URL, or JavaScript?
</code></pre>
That is much more useful.
XSS is not only about finding payloads.
A payload only proves the issue. The real skill is understanding why the payload worked in that specific context.
<h2>What I Practised in the Labs</h2>
<img src="https://media.daily.dev/image/upload/s--feHYcijv--/f_auto/v1779360863/ugc/content_f2930b1f-1ab3-45a9-9b59-65f1e8ae3c39?_a=BAMAMiWQ0" alt="d0eb30c9-1919-416c-9200-e34a910737a3.png">
In the labs, I focused on understanding the behaviour rather than memorising payloads.
The practical process was usually:
<pre><code>1. Find where user input enters the application.
2. Check whether the input is reflected, stored or processed by JavaScript.
3. Look at the response or DOM.
4. Identify the rendering context.
5. Test whether the browser treats the input as data or code.
6. Think about the correct remediation for that context.
</code></pre>
This helped me avoid a common beginner mistake: trying random payloads without understanding why they should work.
The better approach was to slow down and ask:
<pre><code>Is my input inside normal HTML?
Is it inside an attribute?
Is it inside JavaScript?
Is it being inserted into the DOM?
Is the application encoding it?
Is the framework protecting me here?
Am I bypassing safe rendering by using an unsafe API?
</code></pre>
That made the labs much more valuable.
I also started to see why XSS can be tricky.
Sometimes the input appears on the page, but it is safely encoded.
Sometimes it is inside an attribute, so the payload needs to break out of that context.
Sometimes the server response looks safe, but client-side JavaScript later reads a value from the URL and writes it into the DOM unsafely.
That is why understanding context is more important than just seeing your input appear on the page.
<h2>What This Taught Me About React and Safe Rendering</h2>
As a React developer, this part was important.
React escapes values by default when rendering text inside JSX.
That is a good protection, but it does not mean React applications are automatically safe from XSS.
The risk increases when developers bypass safe rendering or pass untrusted data into dangerous places.
For example:
<pre><code>Using dangerouslySetInnerHTML with untrusted content
Using innerHTML or insertAdjacentHTML
Building URLs from untrusted input
Trusting API or CMS content without validation
Using markdown or rich text renderers without proper sanitisation
Injecting third-party scripts without review
</code></pre>
The important lesson is that framework protections help, but they do not replace secure thinking.
React can make some XSS patterns harder, but developers can still introduce XSS if they use unsafe APIs or render untrusted content in the wrong context.
This made me think differently about frontend work.
When rendering user-controlled data, I should not only ask whether the component works visually.
I should also ask:
<pre><code>Where did this data come from?
Can the user control it?
Is it rendered as text or HTML?
Is it going into an attribute or URL?
Is any library transforming it?
Is sanitisation needed?
Is output encoding handled correctly for this context?
</code></pre>
That is a very practical shift.
<h2>Developer Remediation</h2>
<img src="https://media.daily.dev/image/upload/s--xVCff8U0--/f_auto/v1779360834/ugc/content_7a3ee140-370e-4618-9f46-8ebc3aece530?_a=BAMAMiWQ0" alt="766b1f15-1db6-4c19-8f86-5611aabd078b.png">
The main remediation for XSS is to treat untrusted data carefully and render it in the correct context.
Good practices include:
<pre><code>Use context-aware output encoding
Prefer safe framework rendering
Avoid inserting raw HTML
Sanitise rich text when HTML is required
Validate and normalise input where appropriate
Avoid dangerous DOM sinks
Use safe APIs for DOM updates
Review markdown and WYSIWYG rendering carefully
Apply a strong Content Security Policy where possible
Test reflected, stored and DOM-based flows
</code></pre>
One important point is that sanitisation and output encoding are not the same thing.
Encoding makes data safe for a specific output context.
Sanitisation tries to clean or remove unsafe content, often when the application genuinely needs to allow some HTML.
For many normal UI values, the safest approach is to render data as text and avoid raw HTML completely.
If rich text is required, it needs proper sanitisation using a trusted library and a clear allowlist of safe elements and attributes.
<h2>Main Takeaways</h2>
The biggest takeaway from this topic is that XSS is not just about executing an alert box.
The alert is only a visible proof that the browser executed something.
The real issue is unsafe data flow.
A better mental model is:
<pre><code>source -&gt; processing -&gt; sink -&gt; context -&gt; browser interpretation
</code></pre>
The second takeaway is that context matters.
The same value can be safe in one place and dangerous in another. HTML body, attributes, URLs, JavaScript and DOM sinks all have different rules.
The third takeaway is that frontend developers are very close to this vulnerability.
We work with rendering every day. We decide how data appears in the UI. We choose components, libraries and APIs. We handle CMS content, API responses, user-generated content and browser state.
That does not mean every XSS issue is a frontend issue.
But it does mean frontend engineers should understand how XSS works.
For me, XSS changed one question in my head.
Before, I would mostly ask:
<pre><code>Does this data render correctly?
</code></pre>
Now I also ask:
<pre><code>Could the browser interpret this data as code instead of text?
</code></pre>
That small shift is probably the most valuable thing I learned from this topic.
<h2>GitHub Notes</h2>
I am keeping my AppSec learning notes and lab summaries here:
<a href="https://github.com/cieslikprzemyslaw/cybersecurity/tree/master/eng/key-web-vulnerabilities/03-cross-site-scripting-xss" target="_blank" rel="noopener nofollow">Cross-Site Scripting XSS notes on GitHub</a>
#appsec #websecurity #xss #frontend #react #javascript #burpsuite

Przemyslaw

A frontend engineer's deep dive into Cross-Site Scripting (XSS) beyond simple alert-box payloads. Covers the source-to-sink mental model, the three XSS types (reflected, stored, DOM-based), and how rendering context determines whether data is safe. Includes React-specific risks like dangerouslySetInnerHTML, unsafe DOM APIs, and untrusted CMS content, plus practical remediation strategies including context-aware output encoding, sanitisation, and Content Security Policy.

# Key Web Vulnerabilities #3: XSS Is Not Just Alert Boxes