Web-Security on IT Comparison

CSRF vs XSS: Forged Requests or Injected Scripts

Mon, 03 Aug 2026 04:27:16 +0900

Overview

CSRF and XSS are both web attacks that abuse a victim’s trusted relationship with a site, but they exploit opposite ends of that trust. CSRF forges a request using the victim’s own session cookie without ever running attacker code in the browser, while XSS smuggles injected script into a vulnerable page so it executes directly inside the victim’s browser.

Comparison Diagram

Comparison Table

Aspect	CSRF	XSS
Attack vector	Forged cross-site request, e.g. an auto-submitting form or image tag on the attacker’s page that targets the victim site	Malicious script injected into a vulnerable page’s HTML or JS output, often via unsanitized user input
Trust exploited	Server’s trust that any request carrying a valid session cookie came from the legitimate user	Browser’s trust that all script served from the site’s origin is safe to execute
Where the payload runs	Nowhere on the victim’s browser beyond a normal HTTP request; the ‘payload’ is the request itself	Attacker’s JavaScript executes directly inside the victim’s browser, in the vulnerable site’s own origin
Prerequisite for success	Victim must have an active authenticated session with the target site when the forged request fires	Vulnerable site must reflect, store, or render attacker-controlled input without proper sanitization or escaping
Attacker capability	Limited to whatever action the victim’s existing session is authorized to perform, like a transfer or settings change	Broad: read cookies and localStorage, capture input, deface the page, or pivot into session hijacking
Primary defense	Anti-CSRF tokens, SameSite cookies, and origin or referer checks	Output encoding, Content Security Policy, and strict input sanitization
Typical impact scope	A single forged action, bounded by what the target endpoint allows	Potential full account takeover or persistent compromise if the injection is stored

Key Differences

CSRF forges a request using the victim’s existing session cookie; XSS injects attacker script that runs inside the victim’s browser.
CSRF requires no code injection into the target site, while XSS depends entirely on unsanitized input reaching the page.
XSS can read and exfiltrate data straight from the DOM, whereas CSRF is limited to blind requests with no response visibility.
SameSite cookies mitigate CSRF but do nothing against XSS, which is stopped primarily by CSP and output encoding.

When to Use Each

CSRF

JWT vs Session-Based Authentication: Stateless Tokens or Server-Tracked State

Mon, 03 Aug 2026 04:24:11 +0900

Overview

JWT and session-based authentication both prove who a user is on every request, but they disagree about where that proof lives. A JWT is a signed, self-contained token the client carries and the server checks locally, while session-based auth hands out a small ID that maps to state the server stores and looks up on every call. That single difference in where state lives cascades into how each approach scales, revokes access, and fits different architectures.

HTTP vs HTTPS: Plaintext vs Encrypted Web Traffic

Sat, 01 Aug 2026 20:01:00 +0900

Overview

HTTP and HTTPS are the same application-layer protocol for transferring web resources, but HTTPS wraps every request and response in a TLS tunnel before it touches the network. That single layer determines whether credentials, cookies, and page content travel as plaintext visible to anyone on the path, or as ciphertext only the two endpoints can read.

Comparison Diagram

Comparison Table

Aspect	HTTP	HTTPS
Default port	80	443
Connection establishment	Single TCP three-way handshake	TCP handshake plus a TLS handshake to negotiate cipher and exchange keys
Certificate requirement	None	X.509 certificate issued by a trusted CA (or self-signed) required
Data encryption	Plaintext — headers, cookies, and body sent unencrypted	Encrypted end-to-end using TLS/SSL symmetric ciphers
Data integrity	No built-in tamper detection	MAC/AEAD in TLS detects in-transit tampering
Browser indicator	“Not secure” warning in modern browsers	Padlock icon; no warning shown
Performance overhead	Lower — no crypto or extra round trip	Slightly higher handshake/CPU cost, largely offset by TLS 1.3 and session resumption
Typical use case	Local development, internal tools on trusted networks, legacy static content	Any production site, especially logins, payments, and APIs handling sensitive data

Key Differences

HTTPS is HTTP tunneled through TLS, not a separate application protocol
HTTP traffic is readable in plaintext by anyone with network access; HTTPS traffic is encrypted
HTTPS requires a valid certificate from a trusted CA to establish trust
Modern browsers flag HTTP sites as not secure, pushing HTTPS as the default
TLS 1.3 has shrunk the historical HTTPS handshake cost to near parity with plain TCP

When to Use Each

HTTP