XSS and CSRF: attacks through the browser

XSS: someone else's script on your page

A script is a piece of JavaScript code. XSS happens when your page shows user text as HTML, and that text contains a <script> tag or similar. The browser cannot tell your code from the attacker's, so it runs it. The script can read the page, steal data, or send requests as the user.

• Stored XSS: the attacker saves the script in your database, for example in a product review. Every visitor who opens that page runs it.
• Reflected XSS: the script is in a link, like /search?q=<script>...</script>. The page repeats the search word back, so whoever clicks the link runs it.

Stop XSS: escape output

Escaping means turning special characters into safe codes so the browser shows them as text. For example < becomes &lt; . The browser then displays a < sign instead of starting a tag.

// UNSAFE: user text is read as HTML
results.innerHTML = '<p>You searched for ' + query + '</p>';

// SAFE: user text is set as plain text
const p = document.createElement('p');
p.textContent = 'You searched for ' + query;
results.append(p);

Template engines and frameworks like React escape text by default, which removes most XSS. The danger comes back when you switch it off, for example with dangerouslySetInnerHTML in React or a "raw" filter in a template. If you must show user HTML (like a rich-text blog post), clean it with a sanitiser library such as DOMPurify.

Two more layers help. A Content-Security-Policy (CSP) header tells the browser which places scripts may load from, so injected inline scripts are blocked. An HttpOnly cookie cannot be read by JavaScript at all, so even if XSS happens, the session cookie cannot be stolen.

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'
Set-Cookie: sid=8f2c...; HttpOnly; Secure; SameSite=Lax; Path=/

CSRF: a forged request with your cookie

Browsers send your cookies with every request to a site, even if the request starts on another site. CSRF uses this. You are logged in to your bank. You open a bad page in another tab. That page has a hidden form that posts "transfer 50,000 to the attacker" to the bank. Your browser adds your bank cookie, and the bank thinks you sent it.

<!-- on the attacker's site -->
<form action="https://bank.example.in/transfer" method="POST">
  <input type="hidden" name="to" value="attacker-account">
  <input type="hidden" name="amount" value="50000">
</form>
<script>document.forms[0].submit();</script>

Stop CSRF: three layers

1. SameSite cookies: set SameSite=Lax (or Strict) on the session cookie. The browser then does not send it on cross-site POST requests. Modern browsers treat cookies as Lax by default, but set it yourself.
2. CSRF tokens: the server puts a random secret token in the session and in each form. On every POST, PUT, PATCH or DELETE it checks that the token sent matches the one in the session. The attacker's page cannot know it.
3. Check Origin: browsers send an Origin header saying which site started the request. Reject state-changing requests whose Origin is not your own site.