XSS, CSRF, Clickjacking and Security Headers

Lesson 1 was injection on the server: user data ended up inside SQL or a shell command. This lesson is the same mistake, but inside the browser. It also covers a cousin attack, CSRF, which does not inject anything and instead tricks the browser into using its own login. We run a tiny local server, drive a real Chromium against it, and see each attack work and then fail.

You can read Browser Lesson 7 (defence in depth for the front-end) and Browser Lesson 3 (where to keep tokens) next to this one. Cookies and sessions are explained in Browser Lesson 2, and the rules for cross-site requests in Browser Lesson 4 (CORS). The next lesson, Passwords and login, is about the thing CSRF and XSS aim at: the session.

Words used in this lesson

• XSS (cross-site scripting) is when an attacker gets their JavaScript to run in another user's browser, on your site.
• Reflected XSS means the bad text is in the request (for example a URL) and the server sends it straight back in the page.
• Stored XSS means the bad text is saved (for example in a comment) and shown to every visitor later.
• DOM-based XSS means the page's own JavaScript writes bad text into the page, for example with innerHTML.
• Output encoding (or escaping) means changing special characters like < into safe codes like <, so the browser shows them as text.
• CSP (Content Security Policy) is a response header that tells the browser which scripts and resources it may run or load.
• CSRF (cross-site request forgery) is when a different site makes the user's browser send a request to your site, and the browser attaches the user's cookie.
• A cookie is a small value the browser stores and sends back to the site that set it.
• A site is the registrable domain (like example.com) and its scheme. Same-site and same-origin are not the same thing; the port does not matter for same-site.
• SameSite is a cookie setting (Strict, Lax or None) that says if the cookie is sent on requests that start from another site.
• A CSRF token is a random secret value that your page includes in each form, and that the server checks. A different site cannot read it.
• Clickjacking means a bad page loads your site in an invisible frame and tricks the user into clicking on it.
• frame-ancestors is a CSP setting that says which sites may put your page in a frame.
• A security header is a response header that tells the browser to turn on a protection.
• HttpOnly is a cookie setting that hides the cookie from JavaScript.

XSS: when text becomes a script

Think of a search page: you type shoes and it shows "Results for shoes". The server has to put your text into the HTML. If it puts it in without changing it, the browser cannot tell your text from the page's own HTML.

Here is the whole vulnerable server route:

// vulnerable: the query text goes straight into the HTMLif (u.pathname === "/bad") out = `<h1>Results for ${q}</h1>`;

Now someone opens http://localhost:3100/bad?q=<script>alert(1)</script>. The server sends this (I fetched it with curl):

<!doctype html><html><body><h1>Results for <script>alert(1)</script></h1></body></html>

The browser sees a real <script> element and runs it. In real Chromium, driven by Playwright, the result was:

/bad  alert fired: ["1"] | h1 text: "Results for alert(1)"

A dialog with 1 opened. Note the heading text: the tag itself disappeared, because the browser treated it as a tag and not as text. The alert(1) is a harmless test. A real attacker would not show a dialog. They would send the user's data to their own server, or click buttons as the user.

This is reflected XSS: the attack travels in a link. The attacker only needs the victim to open that link (in an email, a chat message or a post). Stored XSS is worse: the attacker posts <script>...</script> as a comment, the server saves it, and every visitor who opens the page runs the script. DOM-based XSS is the same thing done by the browser-side code, for example el.innerHTML = location.hash.

What a script can do on your page

Once the attacker's script runs on your page it has all the power of your own code on that origin. It can read the page, call your API with the user's session, change what is shown (a fake login form), and read localStorage. An HttpOnly cookie cannot be read by JavaScript, but the script can still use the logged-in session by making requests, so HttpOnly reduces the damage and does not stop it. See Browser Lesson 3 for this trade-off.

The fix: encode the output for where it lands

The cure has the same shape as in lesson 1: keep data as data. When you put text into HTML, change the characters that HTML treats as special, so they become plain text. Here is a tiny function and the route that uses it:

const esc = (s) => String(s)  .replace(/&/g, "&amp;").replace(/</g, "&lt;").replace(/>/g, "&gt;")  .replace(/"/g, "&quot;").replace(/'/g, "&#39;");if (u.pathname === "/good") out = `<h1>Results for ${esc(q)}</h1>`;

The same attack:

<!doctype html><html><body><h1>Results for &lt;script&gt;alert(1)&lt;/script&gt;</h1></body></html>

/good alert fired: [] | h1 text: "Results for <script>alert(1)</script>"

No dialog. The browser shows the text <script>alert(1)</script> on the page as ordinary words. That is exactly what the user typed, which is the right outcome.

The OWASP XSS Prevention cheat sheet puts this as its first rule: when you want to show data as the user typed it, use output encoding, and start with the protection your framework already gives you.

Your framework already helps, until you turn it off

React, Vue, Angular and most template engines encode text by default. In React, {name} is safe. The danger is in the escape hatches:

The OWASP cheat sheet makes the same point: no framework is perfect, and you need to know where yours has gaps. The words "dangerously" and "unsafe" in an API name are a warning, so search your code for them.

If you really must allow some HTML from users (a rich text editor), do not write your own filter. Use a well-tested HTML sanitiser library (for example DOMPurify in the browser) with a small allow-list of tags, and keep it up to date. Sanitising is a harder job than encoding, so prefer plain text where you can.

CSP: a safety net behind the encoding

Encoding stops XSS if you never forget it. But people forget. A Content Security Policy is a second layer: a header in which the server tells the browser what it may run. If an injected script gets into the page, the browser can refuse to run it.

Here is the same vulnerable page, but now the server also sends a CSP header. The server code is the same as before, with one more header:

headers["content-security-policy"] = "default-src 'self'; script-src 'self'";

Meaning: by default only load things from my own origin ('self'), and run scripts only if they come from my origin as files. Inline scripts, written inside the page, are not allowed. I checked the header with curl:

content-security-policy: default-src 'self'; script-src 'self'

And the same <script>alert(1)</script> attack, in real Chromium:

/csp  alert fired: [] | h1 text: "Results for alert(1)" | console: Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution.

The page was still built wrongly (the injected <script> tag is still in the HTML), but the browser said "Refused to execute inline script" in its console, and no dialog opened. The mistake was not exploited. That is defence in depth (lesson 0) in practice.

The error text also tells you the three ways to allow an inline script: 'unsafe-inline' (which turns the protection off, avoid it), a hash of the script, or a nonce (a random value that changes on every response, placed in both the header and the script tag). The OWASP CSP cheat sheet leads with the idea that a strict policy based on nonces or hashes is the better choice than long lists of allowed domains.

What does the OWASP CSP page list that a policy can do? I read four goals: block inline scripts, restrict where remote scripts load from, restrict eval-style text-to-JavaScript functions, and restrict where forms can submit to (form-action).

A starter policy that many apps begin with, then adjust:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

CSRF: the browser sends the cookie for you

Now a different attack. No script is injected into your site. Instead, the user is logged in to bank.com in one tab, and opens evil.com in another. The evil page contains a hidden form that submits a request to bank.com/transfer. The browser sends the request and, because the cookie belongs to bank.com, attaches the user's cookie automatically. The bank cannot tell it from a request the user meant to make.

The bank only checks "is there a valid session cookie?" and does the action. That is CSRF: the server trusts the cookie, and the cookie is attached no matter who started the request. The attacker never sees the cookie or the response. They only need the action to happen.

The experiment

My toy "bank" has two routes: /login (sets a cookie sid=abc123) and /transfer (needs the cookie, then subtracts 50 from a balance). My "evil" page, served from a different site, auto-submits a POST form to the bank:

<body onload="document.forms[0].submit()">  <h1>You won a prize</h1>  <form method=post action="http://localhost:3100/transfer"></form></body>

For each cookie setting I logged in with a fresh browser profile, opened the evil page in another tab, and read the result:

cookie SameSite=none-set -> evil POST result page: "sent 50, balance 50"cookie SameSite=None     -> evil POST result page: "sent 50, balance 0"cookie SameSite=Lax      -> evil POST result page: "not logged in"cookie SameSite=Strict   -> evil POST result page: "not logged in"

(The balance carries over between rows because it is one server variable. It starts at 100, so the first two rows moved 50 each.)

Look at what happened:

• With SameSite=None (plus Secure, which Chrome requires with None), the cookie was sent on the cross-site POST and the money moved. The attack worked.
• With SameSite=Lax and SameSite=Strict, the browser did not send the cookie on the request that came from the other site, so the bank said "not logged in". The attack failed.
• The first row is the surprise. I set no SameSite attribute and the attack still worked, in this Chromium. Modern browsers treat a cookie without the attribute as Lax, which should block it. What I saw matches a Chrome rule I know of as a short "Lax-plus-POST" exception for new cookies without an explicit SameSite, but I did not find a source to read, so treat this as an observation and not a rule. The lesson is clear either way: write the SameSite attribute yourself. Do not depend on the default.

The OWASP CSRF Prevention cheat sheet says the same thing in its own order: for stateful apps, use the synchronizer token pattern; for stateless ones, double submit cookies; and SameSite on session cookies helps, with a warning not to set the cookie for a whole domain, because then every subdomain shares it.

SameSite in plain words

A good default for a session cookie is:

Set-Cookie: sid=...; HttpOnly; Secure; SameSite=Lax; Path=/

Lax still lets the user arrive from an outside link while logged in, which people expect. Strict is safer, and users may need to log in again after a click from an email.

The CSRF token

SameSite stops most CSRF in modern browsers, but the standard second layer is a CSRF token: a secret random value that is part of the real form and checked by the server. The evil site cannot read your pages (the browser blocks that, see CORS in Browser Lesson 4), so it cannot know the token.

<!-- served only to the logged-in user --><form method=post action=/transfer-safe>  <input type=hidden name=csrf value=TOKEN-FOR-abc123>  <button>Send 50</button></form>

The server compares the csrf field to the token it stored for this session. I tested both a forged POST (cookie, but no token) and the real form post, with Playwright's request API:

forged POST without token: 403 blocked: missing or wrong csrf tokenreal form POST with token: 200 sent 50, balance -50

The forged request is refused. (The negative balance is just because my toy app has no "insufficient funds" check, which would be another bug, a business-logic one.)

Other defences from the same cheat sheet: check the Origin or Referer header, and use the Fetch Metadata header Sec-Fetch-Site, which tells the server if the request came from the same site. The OWASP page says these headers are supported by all major browsers since March 2023, and that an old-browser fallback to checking the Origin is a must if you use them. Also, JSON APIs that need a custom header like Authorization: Bearer ... are not exposed to classic CSRF, because a plain HTML form cannot add such a header. If you keep your token in localStorage you trade CSRF for XSS risk (see Browser Lesson 3).

CSRF and XSS are different, but they connect

An XSS hole beats every CSRF token, because the attacker's script runs on your origin and can read the token. This is why XSS is treated as the more serious of the two.

Clickjacking: an invisible frame

A bad page can load your site inside an <iframe>, make it invisible (or covered by a fake button), and place it so the user's click lands on your real "Delete account" button. The user thinks they are clicking on a free game.

The defence is to tell the browser which sites may frame your pages. The modern way is the CSP frame-ancestors directive:

Content-Security-Policy: frame-ancestors 'none'

'none' means nobody may frame it. 'self' means only my own origin. You can also list sites. The older header X-Frame-Options: DENY (or SAMEORIGIN) does the same job and is still sent for old browsers. OWASP's clickjacking page names both as the main defences.

I put the "bank" page under this header and framed it from the evil site's page, together with a normal page for comparison:

iframe f | frame url:  | text: "localhost is blocked ... localhost refused to connect. ... ERR_BLOCKED_BY_RESPONSE"iframe g | frame url: http://localhost:3100/good?q=hi | text: "Results for hi"

Frame f, the page with frame-ancestors 'none', was blocked: Chromium showed its error page with ERR_BLOCKED_BY_RESPONSE instead of the content. Frame g, which has no such header, loaded normally and could be clicked through. If the page that is framed can do something important with one click, set this header.

The security headers worth setting

Many protections are just response headers. You can set them by hand, or use helmet, an npm package for Node servers that sets a group of them. I installed helmet 8.3.0 into a clean folder, used it as one line (helmet() with default options), and printed the headers:

Content-Security-Policy: default-src 'self';base-uri 'self';font-src 'self' https: data:;form-action 'self';frame-ancestors 'self';img-src 'self' data:;object-src 'none';script-src 'self';script-src-attr 'none';style-src 'self' https: 'unsafe-inline';upgrade-insecure-requestsCross-Origin-Opener-Policy: same-originCross-Origin-Resource-Policy: same-originOrigin-Agent-Cluster: ?1Referrer-Policy: no-referrerStrict-Transport-Security: max-age=31536000; includeSubDomainsX-Content-Type-Options: nosniffX-DNS-Prefetch-Control: offX-Download-Options: noopenX-Frame-Options: SAMEORIGINX-Permitted-Cross-Domain-Policies: noneX-XSS-Protection: 0

In plain words, what the important ones do:

I skimmed the OWASP HTTP Headers cheat sheet, which lists many such headers and gives recommended values. I did not copy those values, I only report what helmet printed when I ran it.

Missing from helmet's list: cookies. Cookie flags are set when you set the cookie (HttpOnly, Secure, SameSite). Helmet does not do that for you.

You can check any site you own with curl -I https://your-site.example and read the headers it sends.

Putting the picture together

Here is the list of layers for a typical web page, in the order I would add them:

1. Encode output for the context (or use a framework that does).
2. Avoid raw HTML sinks: innerHTML, v-html, dangerouslySetInnerHTML. Sanitise with a library if you must.
3. Cookies: HttpOnly; Secure; SameSite=Lax (or Strict), set explicitly.
4. CSRF token for any state-changing cookie-based request, and never change data on GET.
5. CSP, first in report-only mode, then enforcing; with frame-ancestors.
6. Other headers (HSTS, nosniff, referrer policy) with helmet or your host's settings.
7. Keep dependencies updated and watch for XSS in third-party scripts. See lesson 6.

Try it

1. Run a tiny node:http server with the /bad route. Open it with ?q=<b>hi</b>. What do you see, and why is this a warning sign even before you use <script>?
2. Add esc() and check the HTML with curl. What did < become?
3. Add Content-Security-Policy: script-src 'self' and open the vulnerable route again. Open the browser console. What does it say?
4. Make a page that sets a cookie with and without SameSite=Lax. Use two hosts (localhost and 127.0.0.1) to try a cross-site POST form. Which cookie arrives?
5. Add a CSRF token to a form. What happens if the token is missing? If it is wrong?
6. Add frame-ancestors 'none' and try to frame your page. What does the browser show?
7. Run npm i helmet, print its headers with curl -I, and write one line about each header in your own words.

Answers

1. The word "hi" appears bold, because the browser read <b> as a tag. That means your text is becoming HTML. If <b> works, <script> can work.
2. < became < and > became >. The browser shows the characters, it does not run them.
3. The console shows a message that the inline script was refused because it violates the Content Security Policy directive.
4. The cookie with SameSite=Lax (or Strict) is not sent on the cross-site POST. The cookie with None; Secure is sent. A cookie with no attribute depends on the browser, which is why you set it yourself.
5. Missing or wrong token: the server returns 403 and does not do the action.
6. A browser error page (in Chromium: ERR_BLOCKED_BY_RESPONSE) instead of your page inside the frame.
7. Compare with the table above. Your own words are the point: if you can explain a header to a teammate, you will remember it.

Interview questions

Key takeaways

• XSS is injection into HTML. Reflected, stored and DOM-based are three delivery routes. Encode output for the exact context, and avoid raw HTML sinks.
• In real Chromium: the unencoded page ran the script, the encoded page showed it as text, and the page with a CSP header refused to run it.
• CSP is a safety net. Prefer nonces or hashes over unsafe-inline, and try report-only first.
• CSRF abuses the cookie that the browser attaches automatically. Set SameSite yourself and add a random session-bound CSRF token. Never change data on GET.
• In my test, SameSite=Lax and Strict blocked a cross-site POST, None and an unset attribute did not.
• Clickjacking is stopped with frame-ancestors (and X-Frame-Options for old browsers). Frame blocking showed ERR_BLOCKED_BY_RESPONSE.
• Use helmet for a sensible header set, then check the real response. Cookie flags are your own job.
• Run attacks only against your own toy app.

What's next

Next: Passwords and login, Lesson 3. XSS and CSRF both aim at the session, so we now look at how to build login safely: why you never store passwords, hashing with a salt, safe sessions, JWT mistakes, MFA and rate limits. Practise now: open the Network tab on a site you build and check which cookie flags and security headers it actually sends.