Web Security interview questions

No. Client-side validation is purely a UX convenience — an attacker can disable JavaScript, edit the request in the browser or Burp, or call your API directly with curl, bypassing it entirely. Security checks (validation, authorization, sanitization) must be enforced on the server, the only place you control. The misconception is treating the browser as a trust boundary; it isn't, because the client runs on the attacker's machine. Client-side checks are great for fast feedback, never for security.

No. Deleting the cookie just removes the credential from your browser — the session record (or a still-valid JWT) on the server typically remains usable until it expires or is explicitly invalidated. An attacker who already captured the token can keep using it. The misconception treats the cookie as the session itself; it is only a pointer to server-side state. Real logout must invalidate the session server-side, or revoke and short-TTL the token.

Mostly no. The destination hostname is sent in the clear in the TLS ClientHello's SNI extension, and your DNS query usually reveals it too, so an ISP or network can see WHICH site you visit even over HTTPS — they just can't read the path or content. Encrypted ClientHello (ECH) and DNS-over-HTTPS can close this gap, but they aren't universal. 'HTTPS hides everything' is the misconception.

No. TLS/HTTPS secures data in transit between client and server; once received, the data is decrypted and handled in plaintext by the app, then stored however the database is configured. Protecting data at rest is a separate concern — disk/column encryption, a KMS, and access control. Conflating 'we use HTTPS' with 'our stored data is encrypted' is a common and dangerous misconception.

No. HTTPS encrypts the channel so attackers can't read or tamper with traffic in transit, but the malicious input still arrives, is decrypted, and is processed by your app exactly as before. SQL injection and XSS are application-layer flaws fixed by parameterized queries and output encoding, not by transport encryption. The misconception assumes encryption sanitizes content — it doesn't; the attacker simply sends the payload over the HTTPS connection.

No. Private/incognito mode only stops the local browser from saving history, cookies, and form data after the session — it does nothing to the network path. Your ISP, employer proxy, DNS resolver, and the sites you log into can all still see your activity. The misconception is 'incognito = invisible'; in reality it is privacy from other people using the same device, not anonymity from the network.

No. POST simply carries parameters in the request body instead of the URL; that body is plaintext and fully visible to anyone who can see the traffic unless HTTPS is used. POST is preferable for state-changing actions and keeps params out of URLs, logs, and browser history, but it provides no confidentiality on its own. The misconception confuses 'not in the URL' with 'encrypted' — only TLS encrypts either method's data in transit.

Untrusted content the model ingests can carry instructions — indirect prompt injection. You can't fully prevent the model from being influenced, so isolate fetched content as data, constrain what tools/permissions the agent has, require confirmation for sensitive actions, and avoid giving it secrets it could be coerced into leaking. Assuming the model will simply ignore injected instructions is exactly the failure mode being exploited.

This is OWASP LLM 'improper output handling': model output influenced by user input can become command injection when fed to a shell or eval. Treat it as untrusted — map intents to a small allow-list of parameterized actions, validate strictly, and sandbox execution rather than running raw generated strings. Trusting the output, raising token limits, or only logging does nothing to stop the injection.

An open redirect on an auth flow lets an attacker craft a trusted-looking login link that, after authentication, sends the user — and potentially an auth code or token — to an attacker-controlled domain, enabling account takeover and convincing phishing. Fix it by strictly allow-listing exact redirect URIs server-side and rejecting anything else. It is not cosmetic and not a performance issue, and HTTPS doesn't help because the attacker's destination can be a valid HTTPS site too.

If the browser automatically attaches the session cookie, a malicious page can trigger the transfer on the victim's behalf — cross-site request forgery (CSRF). Defend state-changing requests with anti-CSRF tokens and SameSite cookies, and check the Origin/Referer header. Cookies prove identity but not intent, a login CAPTCHA does nothing for an already-authenticated action, and HTTPS protects transport confidentiality, not request forgery.

If an attacker can upload a server-executable file (or HTML/SVG) into a servable directory, they may achieve remote code execution or stored XSS. Validate the real content type, store uploads outside the web root or on a non-executing store, randomize filenames, and serve them so they can't be executed or interpreted as markup. Slower page loads and disk usage are operational issues, not the security risk an attacker exploits here.

Server-side fetching of attacker-controlled URLs is server-side request forgery (SSRF): it lets an attacker reach internal-only services or the cloud metadata endpoint to steal credentials. Mitigate by allow-listing permitted hosts and schemes, blocking private and link-local ranges (re-checking after every redirect), and hardening metadata access with IMDSv2. Saying there's no risk ignores the access the fetch grants, and a loading spinner or response caching does nothing about where the server is allowed to connect.

This is broken access control (IDOR): the server isn't checking that the authenticated user may access the requested object. The fix is per-object authorization enforced server-side on every request. Sanitizing the number doesn't establish ownership. Encrypting or obfuscating the ID is obscurity that's still guessable, leakable, or replayable. The HTTP method is irrelevant to authorization. Always verify the caller's right to the specific object before returning it.

`alg: none` lets anyone craft a valid-looking unsigned token and impersonate any user — a full authentication bypass, not a minor finding. Fix it by allow-listing the expected algorithms server-side and always verifying the signature with the right key; never trust the token's own alg header to pick the verification method. Longer expiry or moving where the token is stored does nothing about forged, unsigned tokens. This is critical and exploitable, so document is not a fix.

Prompt injection can't be fully solved with more prompt text; assume the model can be subverted and constrain what it's allowed to DO. Give tools least privilege, gate high-impact actions behind human confirmation, and validate or sandbox tool calls before acting (OWASP LLM 'excessive agency' and 'improper output handling'). System-prompt pleading is bypassable. Higher temperature only adds randomness, and logging alone records the damage without preventing the injected action.

This is a mass-assignment (over-posting) flaw: the server blindly maps client JSON onto sensitive model fields. Fix it by binding only an explicit allow-list of permitted fields (DTOs / strong params) so privileged attributes like isAdmin can't be set by the client. Hiding the field in the frontend and adding client-side validation are both bypassed by a raw request. Renaming isAdmin is obscurity that's easily discovered. Control which fields bind, server-side.

Parameterized queries are the actual fix: they separate code from data so user input is always treated as a value, never as SQL that can change the query's structure. Manual escaping is error-prone and bypassable across encodings and dialects. A WAF is a compensating control, not a fix, and encoding tricks defeat it. A length check doesn't stop injection at all. Fix it at the query layer.

Stored XSS is fixed by encoding data for the exact context where it's rendered (HTML body, attribute, JavaScript, URL) so the browser treats it as text, with a Content-Security-Policy as a second layer. Blacklisting the word 'script' is trivially bypassed via event handlers, mixed case, and encodings. You can't make your users disable JavaScript. Asking users not to enter HTML isn't an enforceable control. Encode on output, every time you render.

Transitive code runs in your app, so a critical CVE is your risk. Assess whether the vulnerable code path is actually reachable, then remediate by bumping or overriding the version (or mitigating) and verify in production. Ignoring it because it's transitive leaves a known hole an attacker can exploit. Suppressing the audit just hides the warning. Reinstalling node_modules pulls the same vulnerable version. Track it through SCA, don't silence it.

Threat modeling is cheapest and most effective at design time, before code locks in decisions: walk the data flows, enumerate threats with a framework like STRIDE, and bake in mitigations, then revisit as the design evolves. Doing it only post-incident or at the annual pentest finds problems after they are expensive to fix and already exposed. And relying on 'careful developers' is a hope, not a repeatable, auditable control.

Prove the vulnerability without harming the client or hoarding their data: show you can read arbitrary data via the DB version, schema, or a single redacted sample, then stop. Dumping the full PII dataset creates breach-notification and data-handling liability for both parties. Dropping a table is destructive and well beyond proof-of-concept. Encrypting the database and demanding a bounty is extortion, not testing — it is a crime, not a finding.

A useful report drives remediation: rank by business risk (likelihood × impact), surface the exploit chains that lead to critical compromise, and give actionable fixes for each finding. Alphabetical ordering buries what matters under what happens to start with 'A'. Longest-writeup-first rewards verbosity over severity. Dropping the lows hides real risk and the patterns the client needs for defense-in-depth, leaving them with a falsely reassuring picture.

Sensitive data should never reach logs: redact or mask at the source first to stop the bleeding, then remediate the historical logs and tighten access. PCI DSS forbids storing full PANs and CVVs this way, and passwords should never be logged at all. 'Internal' logs are still a prime breach target. Encrypting or ACLing the store still leaves cleartext secrets sitting in logs for anyone with read access — backups, SIEM pipelines, and admins all see them.

Direct prompt injection is when a user types adversarial instructions straight into the prompt to override the system prompt or safety rules. Indirect prompt injection hides malicious instructions inside external content the model later ingests — a web page, email, PDF, or RAG document — so the attack fires without the victim ever typing it. Indirect injection is the bigger risk because the attacker and the victim are different people, and the payload rides in on data the app implicitly trusts.

Insecure output handling is trusting what the model returns and passing it to a downstream system without validation or encoding. Because model output is attacker-influenceable, rendering it as raw HTML causes XSS, feeding it to a URL fetcher causes SSRF, and passing it to a shell or SQL query causes command or SQL injection. The fix is to treat model output exactly like untrusted user input: context-aware output encoding, allowlisting, sanitization, and parameterization before it reaches any sink.

The OWASP Top 10 for LLM Applications is the consensus list of the most critical risks when building with large language models. The 2025 edition covers prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. It exists because traditional appsec lists don't capture LLM-specific failure modes, and it gives teams a shared vocabulary and a checklist to prioritize controls.

RAG security means treating every retrieved document as untrusted input. Key risks: indirect prompt injection hidden in retrieved content, poisoning of the knowledge base or embeddings, and missing per-user authorization so the model returns data the user can't access. Defenses include access control enforced at retrieval, content provenance and ingestion vetting, treating retrieved text as data not instructions, output validation, and isolating the vector store per tenant.

An LLM agent turns text into actions via tools and function calls, so a prompt injection becomes a real-world action — the excessive-agency risk. Secure it by giving each tool the least privilege and scope it needs, validating and constraining tool arguments, requiring human confirmation for sensitive or irreversible actions, sandboxing execution, rate-limiting and budgeting calls, and logging every tool invocation. Never let the model's untrusted-data-influenced output directly authorize a high-impact action.

SPF publishes which IPs may send mail for a domain. DKIM adds a cryptographic signature so the receiver can verify the message was not altered and came from the domain. DMARC ties SPF/DKIM results to the visible From: header via 'alignment', tells receivers what to do on failure (none/quarantine/reject), and sends reports. SPF and DKIM alone do not protect the From a user sees — DMARC is what enforces that.

Embed security at every SDLC phase rather than testing at the end: requirements include security and privacy requirements, design includes threat modeling, development follows secure coding standards with SAST, testing adds DAST and reviews, and release requires sign-off — all governed by policy, separation of duties, and change control. Fixing flaws early is dramatically cheaper than after release.

A JWT is three base64url parts — header, payload (claims), and signature — joined by dots. The server signs the header and payload with a secret or private key, and verifies that signature on each request to trust the claims without server-side session state. Pitfalls: accepting alg=none, RS256-to-HS256 key confusion, not validating expiry/issuer/audience, putting secrets in the readable payload, and no revocation path.

The app redirects the user to the authorization server to log in and consent. The server redirects back with a short-lived authorization code. The app's backend then exchanges that code (plus its client secret) at the token endpoint for an access token, over a server-to-server back channel. This keeps tokens out of the browser/URL. Public clients add PKCE to bind the code to the original requester.

Lockfiles pin exact dependency versions and hashes so every build resolves the same, verified bytes — making builds reproducible and blocking silent malicious updates. Pinning by digest, verifying integrity hashes, and scoping internal packages to a private registry also defend against dependency confusion, where an attacker publishes a higher-version public package matching an internal name to hijack resolution. The principle: never let the build silently pull unverified code.

SAST reads source code without running it, finding flaws like injection sinks early but with many false positives. DAST attacks the running app from the outside with no code visibility, finding real exploitable issues but late and with shallow coverage. IAST instruments the running app to correlate runtime behavior with code, getting accurate results with code context, but needs an exercised application and agent support.

Use defense in depth: pre-commit hooks (e.g. gitleaks) catch secrets before they ever land, server-side CI scanning catches what slips past, and periodic full-history scans find old leaks. Critically, a secret that reached a remote repo must be treated as compromised and rotated — deleting the commit doesn't help because it lives in history, forks, and logs. Pair this with a real secrets manager so secrets aren't in code at all.

Break the build only on high-confidence, high-severity, newly introduced findings; warn (don't block) on everything else so developers keep trust in the gate. Manage false positives with tuned rules, baselining of pre-existing issues, and documented, time-boxed, reviewed suppressions rather than disabling scanners. A gate that cries wolf gets ignored or bypassed, so signal quality is the whole game.

Shifting left means moving security earlier — into design, the IDE, and the pull request — where issues are cheaper to fix than in production. You avoid blocking developers by making the secure path the easy path: fast in-context feedback, low-false-positive gates that only hard-fail on high-severity new issues, secure defaults and paved-road templates, and treating security as enablement rather than a late veto.

SCA inventories the open-source and third-party components an application pulls in — including transitive dependencies — and flags those with known CVEs or problematic licenses. It matters because most modern code is dependencies you didn't write, and a single vulnerable transitive package (like Log4j) can expose the whole app. Good SCA prioritizes by reachability and exploitability, not just raw CVE counts.

An SBOM is a machine-readable inventory of every component, library, and dependency in a piece of software, with versions and ideally hashes. It matters because when a new vulnerability drops, you can query your SBOMs to instantly answer 'are we affected and where?' instead of scrambling. The two dominant standards are SPDX and CycloneDX, and SBOMs are increasingly required by regulation and procurement.

Encoding (like Base64) is a reversible format change with no secret — not security. Encryption is reversible with a key and protects confidentiality. Hashing is a one-way function producing a fixed-length digest, used for integrity checks and password storage, and cannot be reversed back to the input.

It confirms XSS. If alert() fired at all, the browser parsed and executed your injected JavaScript in the page context — that is the vulnerability. A blank/empty popup just means the string argument you passed didn't render as expected (quote handling, encoding, or context mangling broke the message), not that the payload is being blocked. The execution sink is live; you refine the payload from here.

No. CORS is not a defense against CSRF — it actually loosens the same-origin policy so a page can read cross-origin responses it otherwise couldn't. CSRF doesn't need to read the response; it just needs the victim's browser to send an authenticated state-changing request. The real defenses are anti-CSRF tokens, the SameSite cookie attribute, and checking Origin/Referer.

No. The padlock means the transport is encrypted and the certificate is valid for that domain — it says nothing about whether the operator is honest or the content is malicious. Free, automated certificates mean phishing and malware sites almost always have a perfectly valid padlock too. HTTPS protects the channel, not the destination.

Keep access tokens short-lived (minutes) so a stolen one expires fast, and use longer-lived refresh tokens to get new access tokens without re-prompting the user. Rotate refresh tokens on every use and detect reuse of a consumed token as a theft signal, revoking the chain. The goal is to balance limiting the window of a compromised token against not forcing users to re-authenticate constantly.

Coordinated vulnerability disclosure is a process where a researcher reports a flaw privately to the vendor, both sides agree on remediation and a timeline, and details are published only after a fix is available (or an agreed deadline lapses). It balances giving defenders time to patch against the public's right to know. A security.txt file and a clear policy make reporting frictionless; bug bounty programs add structured rewards on top.

The WSTG is a checklist-backed methodology that walks an app through testing categories: information gathering, configuration and deployment, identity and authentication, authorization, session management, input validation (injection/XSS), error handling, cryptography, business logic, and client-side. It gives systematic coverage with stable test IDs so findings are reproducible and nothing obvious gets skipped.

PTES defines seven phases: pre-engagement (scope, rules of engagement, authorization), intelligence gathering (OSINT, recon), threat modeling, vulnerability analysis, exploitation, post-exploitation (pivoting, data of value, persistence), and reporting. The structure makes engagements repeatable, defensible, and tied to business risk rather than ad-hoc hacking — pre-engagement and reporting are the phases juniors underrate.

Start by understanding the app's threat model and where it handles untrusted input, secrets, authentication, and authorization. Use SAST to scan broadly and DAST against the running app, but treat tool output as leads, not findings — triage out false positives. Then spend human time on the high-value, context-dependent areas tools miss: authz logic, business logic, crypto usage, and trust boundaries. Trace data flow from source to sink.

A secure SDLC embeds security into every phase rather than testing at the end: requirements (security and abuse cases), design (threat modeling), implementation (secure coding standards, SAST/SCA in the IDE and CI), testing (DAST, pentest), release (gates and sign-off), and operations (monitoring, patching, feedback). Shift-left moves defects earlier where they're cheap to fix; maturity models like OWASP SAMM and BSIMM measure how well you actually do it.

Threat modeling answers four questions: what are we building, what can go wrong, what do we do about it, and did we do a good job. You diagram the system (often a data flow diagram with trust boundaries), enumerate threats with a framework like STRIDE, prioritize by risk, and assign mitigations. PASTA adds a risk- and attacker-centric flavor; attack trees decompose a single goal. Doing it at design time is far cheaper than patching production.

A forward proxy sits in front of clients and makes outbound requests on their behalf — used for egress control, filtering, caching, and anonymity. A reverse proxy sits in front of servers and receives inbound requests on their behalf — used for load balancing, TLS termination, caching, and as a security front for a WAF. The direction it faces, client-side or server-side, is the key distinction.

Identify the stack from headers and source, then brute force directories and files with gobuster or feroxbuster using a good wordlist and relevant extensions. Look for admin panels, backups, config files, and upload points, and check virtual hosts when the site responds to a hostname.

Individually, SQLi exposes or modifies data and can reach RCE; stored XSS hijacks sessions in victims' browsers. Chained, you can use SQLi to plant a stored XSS payload that fires in an admin's session, steal their session, and escalate to full application control.

A pentest moves through pre-engagement (scope and rules of engagement), reconnaissance, scanning and enumeration, exploitation, post-exploitation, and reporting. Each phase feeds the next, and reporting is where the value is actually delivered to the client.

A vulnerability scan is an automated, breadth-first inventory of potential weaknesses, often with false positives. A penetration test is human-driven: it validates findings, chains them together, and demonstrates real business impact through actual exploitation.

A good report serves two audiences: an executive summary that frames business risk for leadership, and detailed, reproducible findings with evidence, accurate risk ratings, and prioritized remediation for the technical team. The report — not the exploit — is the deliverable.

A secure SDLC bakes security into every phase rather than bolting it on at the end. Requirements include security and abuse cases, design adds threat modeling, development uses secure coding and SAST plus dependency scanning, testing adds DAST and pen testing, and operations adds monitoring, patching, and incident response — shifting security left.

Enforce TLS everywhere, authenticate every request (e.g. OAuth2/OIDC tokens), and authorize per-object so users can only reach their own data. Add input validation, rate limiting and quotas, schema validation, and thorough logging. The most common API flaw is broken object-level authorization, so check ownership on every resource access.

Examine the email safely without clicking: check the headers and sender authentication (SPF/DKIM/DMARC), inspect URLs and attachments in a sandbox or with reputation tools, then scope it — who else received it, did anyone click or enter credentials. Based on findings, remediate by purging the email, blocking indicators, and resetting any exposed credentials.

Content-Security-Policy is an HTTP response header that tells the browser which sources of scripts, styles, images, and other content are allowed to load and execute on a page. By disallowing inline script and untrusted origins — ideally via nonces or hashes — it acts as a defense-in-depth backstop that neutralizes injected XSS payloads even when one slips through.

CSRF tricks a logged-in user's browser into sending a state-changing request to a site where they are authenticated, abusing the fact that cookies are sent automatically. It is stopped with anti-CSRF tokens (a secret per-session value the attacker cannot read or guess) and the SameSite cookie attribute, which stops cookies from riding along on cross-site requests.

The OWASP Top 10 is a community-driven awareness document that ranks the most critical web application security risks, refreshed every few years from real-world data. It is not a checklist or standard but a starting point — recent entries include Broken Access Control (#1), Cryptographic Failures, Injection, and Insecure Design.

Never store passwords in plaintext or reversibly encrypted, and never with fast general-purpose hashes like MD5 or SHA-256. Use a slow, memory-hard password hashing function — Argon2id (preferred) or bcrypt — with a unique random salt per password and a tuned work factor, so an attacker who steals the database cannot feasibly crack the hashes.

Prepared statements send the query template to the database first, with placeholders, so the structure is fixed before any user data arrives. Parameters are then bound as pure data and can never be parsed as SQL — so input like ' OR 1=1 is treated as a literal string, not code. This separation is the canonical, reliable fix for injection.

The primary defense is contextual output encoding — encode untrusted data for the exact place it lands (HTML body, attribute, JavaScript, URL). Pair that with safe DOM APIs (textContent over innerHTML), framework auto-escaping, input validation, and a Content-Security-Policy as a defense-in-depth backstop that limits what scripts can run.

The Same-Origin Policy is the browser rule that script from one origin (scheme + host + port) cannot read responses from a different origin, which protects authenticated sessions. CORS is a controlled relaxation: a server returns Access-Control-Allow-Origin headers to explicitly opt in to letting specific origins read its responses, so it loosens SOP rather than bypassing it.

HttpOnly hides the cookie from JavaScript so XSS cannot steal it via document.cookie. Secure ensures the cookie is only sent over HTTPS, blocking network interception. SameSite controls whether the cookie is sent on cross-site requests, mitigating CSRF. Together they harden session cookies against the most common theft and abuse paths.

Key security headers include Strict-Transport-Security (forces HTTPS, blocks SSL stripping), Content-Security-Policy (limits script sources, mitigates XSS), X-Frame-Options or CSP frame-ancestors (blocks clickjacking), X-Content-Type-Options: nosniff (stops MIME sniffing), and Referrer-Policy (controls referrer leakage). Each addresses a specific attack class.

SQL injection lets attacker input alter a query. In-band techniques return data directly: union-based appends a UNION SELECT to pull extra columns, and error-based leaks data through database error messages. When no output is visible, attackers use blind SQLi — boolean-based infers data from true/false response differences, and time-based uses delays like SLEEP() to read data one bit at a time.

SSRF tricks a server into making HTTP (or other) requests to a destination the attacker chooses, abusing the server's network position to reach internal services behind the firewall. In the cloud it is especially severe because the instance metadata service (e.g. 169.254.169.254) can hand back IAM credentials, turning an SSRF into cloud account compromise.

HTTP is stateless — each request is independent and carries no memory of prior ones. Sessions add state on top: after login, the server issues an identifier the browser stores in a cookie and replays on every request. Server-side sessions keep the state on the server keyed by an opaque session ID; stateless tokens like JWTs put signed state in the token itself so the server can verify without storage.

All XSS injects attacker-controlled script into a victim's browser. Stored XSS persists the payload on the server (e.g. a comment) and hits everyone who views it; reflected XSS bounces the payload off the server in a single response, usually via a crafted link; DOM-based XSS never reaches the server logic — vulnerable client-side JavaScript writes untrusted input into the page.

XXE abuses an XML parser that resolves external entities defined in a document's DTD. An attacker declares an entity pointing at a local file or internal URL, and the parser fetches it — enabling file disclosure, SSRF, and denial of service. The fix is to disable DTD processing and external entity resolution in the parser configuration.