Web-Security

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 CSRFXSSVictim Browseractive session cookieAttacker Siteforged auto-submit formTarget Servere.g. bank / app backendAction Executedusing victim's cookievisits pagecookie auto-attachedno injected codeVulnerable Siterenders unsanitized inputInjected <script>runs in page's own originVictim Browserexecutes attacker JSAttacker Serverreceives stolen datainput reflected as codefull DOM accesscookie exfiltrated 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 ...

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. ...

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 HTTPClientServerGET /login?pwd=hunter2visible to anyone on pathHTTPSClientServerx8f#9a2$qL0e...TLS-encrypted, tamper-evident 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 ...