Web security is the practice of protecting websites and web applications from attacks that steal data, hijack sessions, or disrupt service — it matters because the web is the most exposed attack surface most organizations have: publicly reachable, constantly probed, and a single vulnerability (an unpatched dependency, an unvalidated input) can expose user data or compromise an entire system.

HTTPS is HTTP layered over TLS — the same request/response semantics, but encrypted, tamper-evident, and backed by a certificate that lets the browser verify it's actually talking to the real server, not an impostor.

SSL (Secure Sockets Layer) is the predecessor protocol, now considered insecure and deprecated everywhere; TLS (Transport Layer Security) is its modern successor and what "SSL" almost always actually means in practice today. Both provide encryption (confidentiality), integrity (detecting tampering), and authentication (verifying server identity via certificates) for data in transit.

A certificate binds a public key to a domain name, digitally signed by a Certificate Authority the browser already trusts — during the TLS handshake, the server presents its certificate, the browser verifies the CA's signature and the domain match, and only then do the two sides establish an encrypted session. The CA's whole job is vouching for that identity binding so a browser doesn't have to trust every server blindly.

// Cookie flags that make a session cookie meaningfully more secure:
Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Strict

A secure session ties a series of requests to an authenticated identity using a token/session ID that's hard to steal or forge — established after successful authentication, transmitted only over HTTPS (Secure flag), inaccessible to JavaScript (HttpOnly, blocking XSS-based theft), and restricted from being sent on cross-site requests (SameSite, mitigating CSRF).

These map closely to the OWASP Top 10 — the industry's regularly-updated, evidence-based list of the most impactful web application security risks, which is worth naming explicitly in an interview as the standard reference point for prioritizing security work.

// Vulnerable: raw user input rendered directly as HTML
element.innerHTML = userComment;   // if userComment contains <script>, it executes

// Safe: render as text, or encode before inserting as HTML
element.textContent = userComment;

XSS injects malicious script into a page that other users then load and execute in their own browser session — stored (persisted in a database, e.g. a comment field), reflected (echoed back in a URL parameter), or DOM-based (client-side JS unsafely inserting untrusted data). Prevent it by encoding/escaping all output by default, using a framework that auto-escapes (React/Angular do by default unless you deliberately bypass it), and setting a Content-Security-Policy as a defense-in-depth backstop.

-- Vulnerable: string-concatenated input becomes part of the query text
-- "SELECT * FROM users WHERE username = '" + input + "'"

-- Safe: a parameterized query — the value is bound, never parsed as SQL
SELECT * FROM users WHERE username = @username;

SQL injection exploits unsanitized input concatenated directly into a SQL query, letting an attacker alter the query's actual logic (bypass a login check, exfiltrate other tables' data, or worse). Parameterized queries/prepared statements are the real fix — the input is bound as data, never parsed as part of the SQL syntax, so no amount of clever input can change the query's structure.

CSRF tricks a logged-in user's browser into submitting an unwanted authenticated request to a site they're already logged into — it works because browsers automatically attach cookies to requests, even ones initiated by a malicious third-party page. Prevent it with anti-CSRF tokens (a per-session/per-form token the server verifies), SameSite=Strict/Lax cookies (blocking the browser from sending the cookie on a cross-site request in the first place), and checking the Origin/Referer header on state-changing requests.