Web Security

Junior Questions

Junior
11

What are secure cookie attributes?

  • HttpOnly — inaccessible to JavaScript. Prevents XSS token theft.
  • Secure — only sent over HTTPS.
  • SameSite=Lax — not sent on cross-site sub-resource requests (CSRF mitigation). Strict = never cross-site. None = always, requires Secure.
  • Session tokens: always use HttpOnly; Secure; SameSite=Lax at minimum.

What problems does this solve?

  • Cookie attributes are the primary defence for session tokens — getting them wrong creates XSS and CSRF vulnerabilities.
Junior
13

What is CORS and how does it work?

  • CORS allows (or blocks) browsers from making cross-origin requests. Enforced by the browser — doesn't protect APIs from server-to-server requests.
  • Simple requests: browser checks Access-Control-Allow-Origin response header.
  • Preflight: Browser sends OPTIONS first for non-simple requests (custom headers, PUT, DELETE).
  • Pitfall: Access-Control-Allow-Origin: * + Allow-Credentials: true is invalid — browsers reject it.

What problems does this solve?

  • CORS is the most misunderstood browser security mechanism — understanding preflight and credentials shows depth.
Junior
14

What is CSRF and how do you prevent it?

  • CSRF tricks a user's browser into sending unwanted requests to a site where they're logged in, exploiting auto-sent cookies.
  • Prevention:
    • CSRF tokens — server-generated random token in each form, verified on submission.
    • SameSite=Lax/Strict — prevents cookies being sent cross-site.
    • Custom headers — APIs using Authorization: Bearer (not cookies) are CSRF-safe.
    • Origin/Referrer header validation.

What problems does this solve?

  • CSRF is subtle — knowing why Bearer token APIs avoid it shows deep understanding.
Junior
17

What is Defence in Depth?

  • Apply multiple independent security layers so that if one fails, others remain. No single control is assumed perfect.
  • Layers example: Firewall → WAF → rate limiting → authentication → authorisation → input validation → output encoding → security headers → monitoring.
  • Complementary: Principle of Least Privilege — grant only minimum permissions needed.

What problems does this solve?

  • Defence in depth is the core philosophy behind enterprise security — thinking in layers is a senior signal.
Junior
19

What is SQL Injection and how do you prevent it?

  • SQL Injection occurs when user input is concatenated directly into SQL queries.
  • Prevention: Always use parameterised queries / prepared statements. Use an ORM. Apply least privilege to DB users. Validate inputs — but never rely on this alone.

What problems does this solve?

  • Parameterised queries are the single non-negotiable fix for SQL injection.
Junior
22

What is XSS and how do you prevent it?

  • XSS occurs when malicious scripts are injected into pages and executed in other users' browsers.
  • Reflected XSS: Script in a URL parameter reflected in the response.
  • Stored XSS: Script persisted in the DB (e.g., comment field) and served to all visitors.
  • DOM XSS: Client-side code writes attacker data to DOM (innerHTML, eval).
  • Prevention: Escape HTML output, use CSP, avoid innerHTML, use textContent for dynamic text, sanitise rich HTML with DOMPurify. React/Vue auto-escape template bindings.

What problems does this solve?

  • XSS is the most common web vulnerability — every developer must know how to prevent it.
Junior
25

What is input validation and sanitisation?

  • Validation: Verify input meets expected format/type/length — reject if not.
  • Sanitisation: Transform dangerous input into a safe form.
  • Always validate on the server — client-side is UX only.
  • Allowlist over denylist — define what's allowed; reject everything else.
  • Context-specific escaping: HTML, SQL, shell, URL each need different treatment.

What problems does this solve?

  • Input handling is the root of most injection vulnerabilities — the allowlist principle is the core mental model.
Junior
27

What is the OWASP Top 10?

  • The OWASP Top 10 is the most recognised list of critical web application security risks:
  • A01 – Broken Access Control — Users acting outside intended permissions (most common).
  • A02 – Cryptographic Failures — Weak encryption, data exposed in transit/at rest.
  • A03 – Injection — SQL, NoSQL, command injection via untrusted input.
  • A04 – Insecure Design — Missing security controls by design.
  • A05 – Security Misconfiguration — Default creds, verbose errors, open cloud storage.
  • A06 – Vulnerable & Outdated Components — Unpatched dependencies.
  • A07 – Identification & Auth Failures — Weak passwords, broken session management.
  • A08 – Software & Data Integrity Failures — Insecure CI/CD, unverified updates.
  • A09 – Security Logging & Monitoring Failures
  • A10 – SSRF

What problems does this solve?

  • The OWASP Top 10 is the starting point for any security conversation in an interview.
Junior
28

What is the Same-Origin Policy?

  • SOP restricts scripts from one origin accessing resources from a different origin (same protocol + host + port).
  • Blocks fetch, XHR, and DOM access across origins — CORS provides controlled exceptions.
  • Not restricted by SOP: form submissions, <img> loads, <script src> tags.

What problems does this solve?

  • SOP is the bedrock of browser security — understanding it explains why both CORS and CSRF exist.
Junior
29

What is the difference between Authentication and Authorisation?

  • Authentication (AuthN): Verifying identity — "Who are you?" (password, token, biometrics).
  • Authorisation (AuthZ): Verifying permissions — "What are you allowed to do?"
  • HTTP: 401 Unauthorized = auth failure (log in). 403 Forbidden = authz failure (no permission).

What problems does this solve?

  • Confusing the two leads to access control security bugs — a classic opening question.

Mid-Level Questions

Mid
2

How do you protect against brute force attacks?

  • Rate limiting on login endpoints (e.g., 5 attempts → 15-min lockout).
  • CAPTCHA after n failed attempts.
  • Progressive delays / exponential backoff.
  • MFA — the strongest defence against credential stuffing.
  • Monitor and alert on unusual login patterns (new country, bulk attempts).

What problems does this solve?

  • A layered approach to brute force shows architectural security thinking rather than single-point solutions.
Mid
3

How does HTTPS / TLS protect data?

  • TLS encrypts data in transit and authenticates the server via a certificate issued by a trusted CA.
  • TLS 1.3 handshake: Client hello → server cert → key exchange (ECDHE) → symmetric encryption begins. 1-RTT (0-RTT for resumed sessions).
  • Use HSTS to prevent downgrade attacks. TLS 1.0/1.1 are deprecated — use 1.2+ (1.3 preferred).

What problems does this solve?

  • Understanding TLS shows you can reason about data-in-transit security — fundamental for any web developer.
Mid
7

What are JWTs and what are their security concerns?

  • JWT = header.payload.signature (Base64URL). The signature validates integrity. Payload is readable by anyone — not encrypted.
  • Concerns:
    • Reject alg: none. Always validate the expected algorithm.
    • Keep payloads free of sensitive data (JWE for encryption).
    • Can't revoke before expiry without a denylist — keep expiry short.
    • Store in httpOnly cookies, not localStorage.

What problems does this solve?

  • JWTs are ubiquitous but have sharp edges — understanding limitations is a senior signal.
Mid
8

What are Open Redirect vulnerabilities?

  • Attacker-controlled redirect via a trusted site's ?next= or ?redirect= param, sending users to malicious URLs.
  • Prevention: Allowlist permitted redirect destinations. Use relative paths only. Warn when redirecting externally.

What problems does this solve?

  • Open redirects enable convincing phishing attacks using trusted-looking URLs — often overlooked.
Mid
10

What are best practices for session management?

  • Generate cryptographically random session IDs (128+ bits). Regenerate on login (prevents session fixation).
  • Set idle and absolute timeouts. Invalidate server-side on logout.
  • Store session data server-side; send only the ID in an httpOnly; Secure; SameSite=Lax cookie.

What problems does this solve?

  • Session management errors are a top cause of account takeovers — knowing the full lifecycle is fundamental.
Mid
12

What are the key security response headers?

  • Content-Security-Policy — restricts script/style/frame sources.
  • Strict-Transport-Security — forces HTTPS. max-age=31536000; includeSubDomains; preload.
  • X-Frame-Options: DENY — prevents clickjacking (superseded by CSP frame-ancestors).
  • X-Content-Type-Options: nosniff — prevents MIME sniffing.
  • Referrer-Policy: strict-origin-when-cross-origin
  • Permissions-Policy — controls camera, mic, geolocation access.

What problems does this solve?

  • Security headers are cheap to add and eliminate entire attack classes — the canonical list is expected knowledge.
Mid
15

What is Clickjacking?

  • Attackers embed the target site in a transparent iframe and trick users into clicking on it.
  • Prevention: X-Frame-Options: DENY or CSP frame-ancestors 'none'.

What problems does this solve?

  • Simple to prevent but devastating when missed — the frame-busting headers are expected knowledge.
Mid
18

What is Multi-Factor Authentication (MFA)?

  • MFA requires 2+ identity factors: something you know (password), something you have (TOTP, YubiKey), something you are (biometrics).
  • TOTP (RFC 6238) — 6-digit code generated every 30s from shared secret + time.
  • WebAuthn / Passkeys — phishing-resistant public-key auth. Private key never leaves the device.
  • SMS is vulnerable to SIM swapping — prefer TOTP or WebAuthn.

What problems does this solve?

  • MFA is the single biggest account security improvement — understanding the spectrum shows current security awareness.
Mid
21

What is Subresource Integrity (SRI)?

  • SRI lets browsers verify external scripts/stylesheets haven't been tampered with by comparing against a cryptographic hash.
  • Critical for CDN-loaded resources — protects against CDN compromise (supply chain).

What problems does this solve?

  • SRI is a simple, high-value control for any app loading from a CDN.
Mid
24

What is an IDOR vulnerability?

  • IDOR occurs when user-controllable input accesses objects without authorisation (A01 – Broken Access Control).
  • Example: GET /api/invoices/1234 — changing to 5678 returns another user's data.
  • Prevention: Object-level authorisation check on every endpoint. UUIDs add obscurity but don't replace auth checks.

What problems does this solve?

  • IDOR is the most reported bug bounty vulnerability — it's a logic flaw, not a code injection issue.
Mid
26

What is rate limiting and how is it implemented?

  • Controls how many requests a client can make in a time window — protects against DoS, abuse, and brute force.
  • Token Bucket — allows bursting. Sliding Window — smoother. Fixed Window — simple but boundary-attack-prone.
  • Return 429 Too Many Requests with Retry-After header.
  • Implement at Nginx/CDN level (before app), API gateway, or middleware (e.g., express-rate-limit + Redis).

What problems does this solve?

  • Rate limiting is foundational API protection — knowing the algorithms shows depth beyond boilerplate middleware.

Senior Questions

Senior
1

How do you manage dependency vulnerabilities?

  • Run npm audit regularly. Use Dependabot, Snyk, or Renovate for automated PRs.
  • Pin exact versions via lock files (package-lock.json). Minimise deps.
  • Use SRI hashes for CDN-loaded scripts.
  • Verify package maintainers — watch for typosquatting.

What problems does this solve?

  • Supply chain attacks are increasingly common — proactive dependency management is a production engineering concern.
Senior
4

How does OAuth 2.0 work?

  • OAuth 2.0 is an authorisation framework — lets third-party apps access resources on behalf of a user without exposing credentials.
  • Authorization Code Flow: User consents → server returns short-lived code → app server exchanges code for access token (server-to-server, never in browser).
  • PKCE — extension for SPAs/mobile to prevent code interception.
  • OpenID Connect (OIDC) adds identity authentication on top of OAuth 2.0.

What problems does this solve?

  • OAuth 2.0 is the industry standard for third-party authorisation — the code flow is expected at mid-to-senior level.
Senior
5

How should passwords be stored?

  • Never store plaintext or with reversible encryption. Use a slow, salted hash:
  • bcrypt — widely used, built-in salting, configurable work factor.
  • Argon2id — OWASP recommended. Memory-hard, resistant to GPU attacks.
  • Never use MD5, SHA-1, or plain SHA-256 for passwords — they are too fast.

What problems does this solve?

  • Weak password storage means all user accounts are compromised in a breach — this is non-negotiable.
Senior
6

How should secrets (API keys, credentials) be managed?

  • Never commit secrets to source control. Use pre-commit hooks (git-secrets, truffleHog).
  • Inject via environment variables in production.
  • Use a secret manager — AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault.
  • Rotate credentials regularly. Apply least privilege.
  • If accidentally committed: rotate immediately, then clean git history (BFG Repo Cleaner).

What problems does this solve?

  • Leaked secrets cause the majority of cloud breaches — this is critical for any developer working in production.
Senior
9

What are SAST and DAST?

  • SAST (Static) — Analyses source code without running it. Runs in CI pipeline. Examples: Semgrep, SonarQube. High false positive rate.
  • DAST (Dynamic) — Tests the running app by sending attack payloads. Examples: OWASP ZAP, Burp Suite.
  • SCA (Software Composition Analysis) — Scans dependencies for known CVEs. Examples: Snyk, Dependabot.
  • Shift left — Integrate security testing early in CI/CD.

What problems does this solve?

  • Knowing security testing vocabulary shows development-lifecycle security awareness.
Senior
16

What is Content Security Policy (CSP)?

  • CSP is an HTTP header that tells browsers which content sources are trusted, restricting XSS vectors.
  • Key directives: default-src, script-src, style-src, img-src, frame-ancestors.
  • Avoid 'unsafe-inline' and 'unsafe-eval'. Use nonce or hash for specific inline scripts.
  • Use Content-Security-Policy-Report-Only to monitor without blocking.

What problems does this solve?

  • CSP is the defence-in-depth layer against XSS — being able to write a policy is a senior signal.
Senior
20

What is SSRF (Server-Side Request Forgery)?

  • SSRF tricks the server into making requests to internal resources (e.g., AWS metadata: http://169.254.169.254/).
  • Prevention: Allowlist permitted URLs/hosts. Block private IP ranges. Use egress proxy with restricted rules. Disable redirects.

What problems does this solve?

  • SSRF is OWASP A10 and increasingly common in cloud environments — a must-know for full-stack/backend roles.
Senior
23

What is Zero Trust security?

  • "Never trust, always verify" — no user, device, or service is trusted by default, even inside the network.
  • Principles: Verify explicitly. Least privilege access. Assume breach.
  • Replaces implicit perimeter trust with identity-aware access control, mTLS between services, micro-segmentation.

What problems does this solve?

  • Zero Trust is the modern security architecture adopted by Google (BeyondCorp) and increasingly required at enterprise scale.
Senior
30

What should a web security checklist cover?

  • Transport: HTTPS/HSTS enforced, TLS 1.2+ only.
  • Headers: CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
  • Input/Output: Parameterised queries, output encoding, allowlist validation.
  • Auth: Secure sessions, MFA, passwords hashed with Argon2/bcrypt.
  • Access Control: Object-level authorisation on every endpoint.
  • Deps: Automated scanning, SRI on CDN assets.
  • Secrets: No secrets in code, secret manager in use, rotation in place.
  • Cookies: HttpOnly; Secure; SameSite=Lax.
  • Rate limiting: Login and sensitive endpoints protected.
  • Logging: Auth events and errors logged, no sensitive data in logs.

What problems does this solve?

  • A mental security checklist shows systematic thinking — interviewers at security-conscious companies walk through exactly this.