Web security interviews test whether you actually understand the attack and the defense, not just the vocabulary — why parameterized queries stop SQL injection, why a bearer token is immune to CSRF in a way a cookie isn't. This covers the full spread, organized by topic, with code, a couple of diagrams, and a mock test at the end.

Web Security Fundamentals

Q1. What is web security, and why is it important?

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.

Q2. Can you explain what HTTPS is and how it differs from HTTP?

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.

Q3. What are SSL and TLS, and what role do they play in web security?

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.

Q4. How do SSL certificates work, and what is the purpose of a Certificate Authority (CA)?

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.

Q5. What is the difference between encryption and hashing?

Q6. Define the concept of a secure session and explain how it is established.

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

Q7. What are some common web security vulnerabilities?

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.

Q8. Can you explain the Cross-Site Scripting (XSS) attack and how to prevent it?

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

Q9. What is SQL Injection and how can you defend against it?

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

Q10. Describe what Cross-Site Request Forgery (CSRF) is and how to prevent it.

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.

Q11. Explain the Same-Origin Policy and its importance in web security.

The Same-Origin Policy restricts a script running on one origin (scheme + host + port) from reading data (like the response of an XHR/fetch) from a different origin, unless that origin explicitly opts in via CORS — it's the browser's foundational isolation boundary, without which any malicious page could freely read your bank's API responses if you happened to be logged in in another tab.

Q12. What is Clickjacking, and what measures can prevent it?

<!-- Response header, blocks the page from being framed at all -->
X-Frame-Options: DENY

<!-- Modern equivalent, via Content-Security-Policy -->
Content-Security-Policy: frame-ancestors 'none';

Clickjacking overlays a transparent iframe of a legitimate site over a decoy page, tricking a user into clicking something they can't actually see (a "like" button, a "transfer funds" confirmation) that belongs to the framed site underneath. X-Frame-Options or the frame-ancestors CSP directive tells the browser to refuse to render the page inside any (or specific) frames at all.

Q13. How can web cookies compromise security, and how do you safeguard against these risks?

• Without HttpOnly, a cookie is readable by JavaScript — an XSS vulnerability can steal it directly
• Without Secure, a cookie can be sent over plain HTTP and intercepted
• Without SameSite, a cookie is sent on cross-site requests, enabling CSRF
• Sensitive data stored directly in a cookie (not just a session ID) is exposed if the cookie is ever intercepted or logged

Q14. What is a Man-in-the-Middle (MitM) attack and how can it be prevented?

A MitM attack intercepts communication between two parties (a user and a server) without either realizing it, letting the attacker read or modify traffic in transit — enabled by unencrypted HTTP or a compromised/trusted-incorrectly certificate. TLS with proper certificate validation, HSTS (forcing HTTPS on every subsequent visit), and certificate pinning (for mobile/native apps) are the standard defenses.

Q15. Describe the concept of session management in web security.

Session management covers how a user's authenticated state is tracked across requests — generating unpredictable session identifiers, expiring sessions after inactivity, invalidating sessions on logout server-side (not just clearing the client's cookie), and regenerating the session ID after login to prevent session fixation attacks.

Authentication and Authorization

Q16. What is the difference between authentication and authorization?

Q17. Explain basic authentication and its weaknesses.

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
// base64(username:password) — NOT encrypted, just encoded

Basic auth sends credentials as base64-encoded username:password on every single request — base64 is trivially reversible, not encryption, so this is only safe layered over HTTPS. Even then, it has no built-in logout, no expiry, and re-sends the actual password on every request rather than a scoped, revocable token.

Q18. What is OAuth, and how does it work?

OAuth 2.0 is a delegation protocol — it lets a user grant a third-party application limited access to their data on another service (e.g. "let this app see my Google contacts") without ever sharing their actual password with that third-party app, via a scoped, revocable access token instead.

Q19. What is OpenID and how does it relate to web security?

OpenID Connect is an identity layer built on top of OAuth 2.0 specifically for authentication (who is this user) rather than OAuth's original authorization focus (what can this app access) — it adds a standardized ID token (a JWT) carrying identity claims, which is why "Sign in with Google/Microsoft" buttons are built on OpenID Connect, not plain OAuth.

Q20. Can you describe Multi-Factor Authentication (MFA) and where it's used?

MFA requires two or more independent proof factors — something you know (a password), something you have (a phone/hardware token), something you are (biometrics) — so a compromised password alone isn't enough to gain access. It's standard on anything sensitive: banking, admin panels, and increasingly enforced by default for any account holding meaningful personal data.

Q21. What is JWT (JSON Web Tokens) and how are they used in authentication?

// header.payload.signature — base64url encoded, dot-separated
{
  "sub": "user123",
  "role": "admin",
  "exp": 1735689600
}

A JWT packages claims (identity, roles, expiry) into a compact, self-contained, digitally signed token — the server can verify its signature without a database lookup, which is what makes JWTs attractive for stateless authentication across distributed services. The trade-off: a signed JWT can't be revoked before its expiry without extra infrastructure (a blocklist), since the server has no built-in way to "forget" a token it already issued.

Q22. How do you securely store user passwords?

// Never store plaintext or a plain (unsalted) hash — use a purpose-built,
// slow, salted hashing algorithm designed to resist brute-forcing:
string hash = BCrypt.Net.BCrypt.HashPassword(plainPassword);
bool valid = BCrypt.Net.BCrypt.Verify(plainPassword, hash);

Never store plaintext passwords, and never use a fast general-purpose hash (MD5, SHA-256 alone) either — use a purpose-built password hashing algorithm (bcrypt, Argon2, scrypt) that's deliberately slow and automatically salts each hash, making brute-force and rainbow-table attacks impractical even if the hash database itself leaks.

Q23. What is Single Sign-On (SSO) and what are its benefits?

SSO lets a user authenticate once with an identity provider and gain access to multiple independent applications without logging in again to each — benefits: fewer passwords for users to manage (and reuse insecurely), centralized access control/revocation (disable one account, lose access everywhere at once), and a single, well-audited point for MFA enforcement.

Q24. Explain role-based access control (RBAC) and how it is implemented.

[Authorize(Roles = "Admin")]
public IActionResult DeleteUser(int id) { ... }

RBAC grants permissions to roles, then assigns roles to users, rather than managing individual user-level permissions directly — a user's access changes by changing their role assignment, and a role's permissions can be adjusted once to affect every user holding it.

Q25. What are the best practices for handling user session timeouts?

• Expire sessions after a reasonable period of inactivity, shorter for sensitive applications (banking) than casual ones
• Invalidate the session server-side on logout, not just clear the client-side cookie
• Warn the user before an active session times out, rather than silently logging them out mid-task
• Regenerate the session ID after any privilege change (login, elevation to admin) to prevent session fixation

Network Security Concerns

Q26. What is a firewall, and how does it contribute to web security?

A firewall filters network traffic based on rules (source/destination IP, port, protocol), blocking everything not explicitly allowed — the first line of defense limiting what can even reach a server in the first place, before any application-level security even comes into play.

Q27. Define a Virtual Private Network (VPN) and its significance in enhancing web security.

A VPN creates an encrypted tunnel between a client and a network, routing traffic through it — significant for securing traffic over untrusted networks (public Wi-Fi) and for giving remote workers secure access to internal resources without exposing those resources directly to the public internet.

Q28. What is an Intrusion Detection System (IDS) vs. an Intrusion Prevention System (IPS)?

Q29. How does a Distributed Denial-of-Service (DDoS) attack work, and how can websites be protected from it?

A DDoS attack floods a target with traffic from many (often compromised, botnet) sources simultaneously, overwhelming its capacity to serve legitimate requests. Protection: a CDN/scrubbing service (Cloudflare, AWS Shield) absorbing volumetric attacks at the edge, rate limiting, and auto-scaling infrastructure that can (to a point) absorb load spikes rather than falling over immediately.

Q30. Explain the concept of a Content Delivery Network (CDN) and its importance in web security.

Beyond its performance role (caching content at edge locations near users), a CDN acts as a security layer in front of the origin server — absorbing DDoS traffic before it ever reaches the origin, and often bundling a WAF for filtering malicious requests at the edge too.

Secure Coding Practices

Q31. What are secure coding practices, and why are they needed?

Secure coding practices are habits and conventions (input validation, parameterized queries, least privilege, avoiding hardcoded secrets) that prevent vulnerabilities from being written into the codebase in the first place — needed because most real-world breaches trace back to a specific, preventable coding mistake, not a sophisticated novel attack technique.

Q32. How can input validation prevent web security threats?

if (!int.TryParse(input, out int id) || id <= 0)
    return BadRequest("Invalid ID");

Validating that input actually matches the expected shape/type/range before it's used anywhere downstream closes off entire categories of attack — malformed input that would otherwise reach a SQL query, a file path, or a shell command never gets that far in the first place. Validate at the boundary, and never trust client-side validation alone since it's trivially bypassed.

Q33. What are parameterized queries, and how do they prevent SQL injection?

Covered above under Fundamentals — a parameterized query separates the SQL structure from the data values, binding user input as data the database engine never interprets as executable SQL syntax, which is the actual root-cause fix for SQL injection (not just input sanitization, which is easy to get subtly wrong).

Q34. Why should developers avoid security through obscurity?

Hiding an implementation detail (an unlisted admin URL, undocumented API endpoints) isn't real security — it just delays discovery, and once found (via scanning, a leaked URL, or trial and error), there's no actual protection left behind it. Real security relies on properly enforced authentication/authorization that holds up even when an attacker knows exactly how the system works.

Q35. How do you securely handle file uploads to prevent web security issues?

• Validate the actual file content/type (magic bytes), not just the filename extension or client-supplied Content-Type
• Store uploads outside the web root (or in blob storage) so they can't be directly executed as server-side code
• Enforce a strict file size limit and scan for malware where relevant
• Rename uploaded files to a generated identifier rather than trusting the original filename

Data Protection and Privacy

Q36. Define Personally Identifiable Information (PII) and discuss how it should be protected.

PII is any data that can identify a specific individual — names, emails, SSNs, addresses, biometric data. It should be encrypted at rest and in transit, access-restricted to only what's operationally necessary, retained only as long as actually needed, and minimized in the first place (don't collect what you don't need).

Q37. What is the General Data Protection Regulation (GDPR), and what are its key tenets?

• Lawful basis and explicit consent required before processing personal data
• The right to access, correct, and erase one's own data ("right to be forgotten")
• Data breach notification within 72 hours of discovery
• Data minimization — collect only what's necessary for the stated purpose

Q38. What are data encryption best practices for sensitive information?

• Encrypt at rest (database-level or column-level for particularly sensitive fields) and in transit (TLS everywhere, no exceptions)
• Use strong, current algorithms (AES-256) — never a broken/deprecated one (DES, MD5 for anything security-relevant)
• Manage keys separately from the encrypted data itself, via a dedicated key management service
• Rotate keys periodically and have a plan for re-encrypting data after a rotation

Q39. Explain data masking and how it can protect sensitive data.

string masked = $"****-****-****-{cardNumber[^4..]}";   // "****-****-****-1234"

Data masking obscures part or all of a sensitive value in contexts where the full value isn't needed — showing only the last four digits of a card number in a UI, or substituting realistic-but-fake data in a non-production/test environment so developers never touch real customer PII.

Q40. What steps can organizations take to ensure data privacy?

• Data minimization — collect and retain only what's genuinely necessary
• Role-based access limiting who can see sensitive data, audited and reviewed periodically
• Privacy-by-design — build privacy considerations into a feature from the start, not bolted on afterward
• Regular privacy impact assessments for new features touching personal data

Advanced Web Security Concepts

Q41. What are security headers, and why are they important?

Security headers tell the browser to enforce protections on the client side, in addition to whatever server-side defenses exist — a layer of defense-in-depth that mitigates classes of attack even if some other individual protection has a gap.

Q42. What is Content Security Policy (CSP) and how does it improve web security?

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; object-src 'none';

CSP declares an allow-list of sources a page is permitted to load scripts, styles, images, and other resources from — even if an XSS vulnerability manages to inject a <script> tag, CSP can prevent it from executing (or from exfiltrating data to an attacker's domain) if that source isn't on the allow-list, which is exactly why it's a strong defense-in-depth layer against XSS specifically.

Q43. Can you explain the role of Subresource Integrity (SRI) in web security?

<script src="https://cdn.example.com/lib.js"
        integrity="sha384-abc123..."
        crossorigin="anonymous"></script>

SRI lets the browser verify a fetched script/stylesheet matches an expected cryptographic hash before executing it — protecting against a compromised or tampered-with CDN silently serving malicious code instead of the library you actually intended to load.

Q44. What is Domain Name System Security Extensions (DNSSEC), and how does it work?

DNSSEC adds cryptographic signatures to DNS records, letting a resolver verify a DNS response genuinely came from the authoritative source and wasn't tampered with in transit — protecting against DNS spoofing/cache poisoning attacks that could otherwise redirect users to a malicious server without them noticing anything wrong in the address bar.

Q45. What is HTTP Strict Transport Security (HSTS) and how can it be used?

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

HSTS instructs the browser to never attempt a plain-HTTP connection to this domain again for the specified duration, automatically upgrading to HTTPS even before the first request goes out — closing the gap where a user's very first visit (or an attacker stripping HTTPS via a downgrade attack) could otherwise expose an unencrypted request.

Security Testing and Audits

Q46. What is penetration testing, and how does it differ from vulnerability scanning?

Q47. How is fuzzing used in security testing?

Fuzzing feeds an application large volumes of malformed, unexpected, or randomly generated input, looking for crashes, hangs, or unexpected behavior that reveals a vulnerability (often memory-safety issues, or unhandled edge cases in a parser) — especially effective at finding bugs a human tester wouldn't think to try manually.

Q48. What are the main objectives of a security audit?

Verify that security controls (access management, encryption, logging) are actually in place and working as intended, identify gaps against a compliance standard or internal policy, and produce a prioritized remediation plan — a systematic health check rather than a one-off vulnerability hunt.

Q49. Can you explain the concept of threat modeling?

Threat modeling systematically identifies what could go wrong in a system before it's built (or as an existing system evolves) — who might attack it, what they'd target, and how — commonly using a framework like STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) to structure the analysis rather than relying on ad hoc guessing.

Q50. What is static code analysis and how it is beneficial in identifying security risks?

Static analysis tools scan source code without executing it, flagging patterns known to be risky — SQL built via string concatenation, hardcoded secrets, use of a deprecated crypto function — catching issues at commit/PR time, before the vulnerable code ever reaches production, far cheaper than finding the same issue via a pen test or a breach later.

Compliance and Standards

Q51. What are some common web security compliance standards?

Q52. Explain the purpose and key aspects of ISO/IEC 27001.

ISO 27001 is an internationally recognized standard for an Information Security Management System (ISMS) — a systematic, risk-based approach to managing security across people, process, and technology, not just a technical checklist. Certification requires demonstrating ongoing risk assessment, documented policies, and continuous improvement, audited by an accredited third party.

Q53. What is PCI DSS and its relevance to web security?

PCI DSS (Payment Card Industry Data Security Standard) sets required security controls for any system that stores, processes, or transmits credit card data — encryption, access control, network segmentation, and regular testing. Any web application handling payments (even indirectly, through a hosted payment page) needs to understand where its PCI scope boundary actually falls.

Q54. Can you discuss the importance of HIPAA compliance in web applications?

HIPAA governs how Protected Health Information (PHI) must be secured in the US — encryption, strict access controls, audit logging of every access to PHI, and formal Business Associate Agreements with any third-party vendor that touches that data. A web application in healthcare needs HIPAA baked into its architecture from day one, not retrofitted after launch.

Emerging Threats and Trends

Q55. How do you stay informed about the latest web security threats?

• OWASP's own resources and the regularly updated Top 10
• CVE databases and vendor security advisories for dependencies actually in use
• Security-focused newsletters, conference talks (DEF CON, Black Hat), and vendor threat-intelligence reports
• Automated dependency vulnerability scanning (Dependabot, Snyk) as a continuous, not one-time, practice

Q56. Can you discuss the implications of quantum computing on web security?

A sufficiently powerful quantum computer could break the math underlying widely used asymmetric encryption (RSA, ECC) via Shor's algorithm — which is why NIST has been standardizing post-quantum cryptography algorithms designed to resist this, and why organizations handling long-lived sensitive data are starting to plan migration paths now, well ahead of when practical quantum attacks might actually materialize.

Q57. What role does artificial intelligence play in web security?

On defense: anomaly detection in traffic patterns, smarter WAF rules, and automated triage of security alerts at a scale humans can't match manually. On offense: AI-assisted phishing content generation, more convincing social engineering, and automated vulnerability discovery — the same underlying capability cutting both ways, which is why this is now a genuine arms race on both sides.

Q58. How can Internet of Things (IoT) devices create web security risks?

IoT devices are often shipped with weak default credentials, receive infrequent (or no) security patches, and run with minimal built-in security hardening — a compromised device becomes a foothold into the broader network, or gets recruited into a botnet used for large-scale DDoS attacks against unrelated targets (as happened with the Mirai botnet).

Q59. What is Zero Trust security architecture?

Zero Trust assumes no request is inherently trustworthy just because it originates "inside" the network perimeter — every request is authenticated and authorized on its own merits, regardless of source, replacing the older "trusted internal network, untrusted external" model that breaks down the moment an attacker gets any foothold inside.

Incident Response and Handling

Q60. What is an incident response plan, and why is it critical?

An incident response plan is a pre-agreed playbook for handling a security incident — who's responsible for what, communication channels, and the steps above — critical because decisions made under the pressure and confusion of an active incident are far worse than ones agreed on calmly in advance.

Q61. Explain the steps you would take after discovering a data breach.

• Contain it immediately — cut off the attacker's access without destroying forensic evidence
• Assess scope — what data, how many records, which systems were actually affected
• Notify affected parties and regulators within legally required timeframes (e.g. GDPR's 72-hour window)
• Remediate the root cause, then conduct a post-incident review to prevent recurrence

Q62. How important is user training in preventing web security incidents?

Extremely — a large share of real-world breaches start with a human being tricked (phishing, social engineering), not a purely technical exploit. No technical control fully substitutes for a workforce that recognizes a suspicious email or knows not to reuse passwords across systems.

Q63. Can you discuss the role of a Security Operations Center (SOC)?

A SOC continuously monitors an organization's systems for security events (via SIEM tooling, log aggregation, and alerting), triaging and responding to incidents in real time — the operational team that turns "we have logs somewhere" into "someone is actually watching them and can act quickly."

Cloud Security

Q64. How does web security change when applications are moved to the cloud?

Physical infrastructure security becomes the cloud provider's responsibility, but you're still fully responsible for identity/access management, network configuration (a misconfigured S3 bucket or security group is an entirely self-inflicted risk), and application-level security — the attack surface shifts, it doesn't shrink.

Q65. What are the shared responsibility models in cloud security?

Every major cloud provider frames security as a shared responsibility — the provider secures "of the cloud" (physical data centers, host infrastructure), the customer secures "in the cloud" (data, IAM, network configuration, application code) — and exactly where that line falls shifts depending on whether you're using IaaS, PaaS, or SaaS, with the provider taking on progressively more as you move up that stack.

Q66. Explain how encryption is handled in the cloud.

Cloud providers offer encryption at rest by default for most storage services, key management services (AWS KMS, Azure Key Vault) for managing encryption keys (either provider-managed or customer-managed for finer control), and TLS for data in transit — the building blocks exist, but you're still responsible for actually enabling and correctly configuring them per resource.

Q67. What special considerations are there for web security with cloud storage services?

• Bucket/container permissions defaulting to private, with public access requiring a deliberate, explicit decision — misconfigured public storage is one of the single most common real-world cloud breaches
• Access logging enabled to detect unusual access patterns
• Signed, time-limited URLs (rather than permanently public objects) for anything that needs temporary external access

Q68. How does a Web Application Firewall (WAF) protect cloud-hosted web applications?

A cloud WAF (AWS WAF, Azure Front Door's WAF, Cloudflare) filters HTTP requests against rules for common attack patterns (SQLi, XSS payloads, known bad IP ranges) before they reach the application, and can rate-limit or geo-block traffic — implemented as a managed cloud service rather than something you have to run and patch yourself.

Security in Web Application Frameworks

Q69. What built-in security features do modern web application frameworks typically include?

Automatic output encoding (defending against XSS by default), CSRF token generation/validation, parameterized query support baked into the ORM, and secure-by-default cookie/session handling — modern frameworks generally try to make the secure path the easy, default path rather than something you have to remember to bolt on.

Q70. How does Ruby on Rails handle web security, and what are its built-in protection mechanisms?

Rails auto-escapes output in views by default (XSS defense), includes CSRF protection on by default for non-GET requests, and its ActiveRecord ORM uses parameterized queries transparently — "convention over configuration" extends to security defaults specifically to reduce how much a developer has to remember to get right manually.

Q71. What are the security features provided by Django for Python web applications?

Django auto-escapes template output, includes CSRF middleware enabled by default, its ORM parameterizes queries automatically, and it ships a Clickjacking-protection middleware and configurable security headers out of the box — a similarly security-by-default philosophy to Rails.

Q72. How does ASP.NET Core enforce web security?

Razor views HTML-encode output by default, anti-forgery tokens are built in for form submissions, Identity provides a hardened authentication system out of the box, and HTTPS redirection/HSTS are one-line middleware additions — the .NET-specific instance of the same broader pattern every modern framework follows.

Q73. What security considerations must be taken into account when using client-side JavaScript frameworks like Angular, React, or Vue.js?

• React/Angular/Vue auto-escape text content by default, but explicit "raw HTML" escape hatches (dangerouslySetInnerHTML, v-html, [innerHTML]) reintroduce XSS risk if fed untrusted input
• API keys/secrets must never be embedded in client-side bundles — anything shipped to the browser is inherently public
• CORS must be configured correctly on the backend API these SPAs call, since the frontend alone can't enforce origin restrictions

Mobile Web Security

Q74. How do mobile web applications pose unique security challenges?

Mobile devices are more likely to connect over untrusted public Wi-Fi, are more easily lost or stolen (raising local-storage/at-rest-encryption stakes), and mobile browsers/webviews sometimes have different (or laxer) default security behaviors than desktop browsers — the same web security fundamentals apply, with a wider and less controlled set of real-world conditions to defend against.

Q75. What steps can be taken to secure mobile APIs and services?

• Token-based authentication (OAuth2/JWT) rather than long-lived embedded credentials in the app binary
• Certificate pinning to resist MitM attacks even on a compromised or malicious network
• Rate limiting and anomaly detection on the API, since mobile clients are especially easy to script/automate for abuse

Q76. Discuss the security implications of third-party libraries in mobile web app development.

A vulnerable or malicious third-party SDK has the same access to the app's data and permissions as your own code — regularly auditing dependencies for known CVEs, minimizing the number of third-party libraries actually included, and reviewing exactly what permissions/data access each one requires are the practical mitigations.

Q77. What are common vulnerabilities found in mobile web applications?

• Insecure local data storage — sensitive data cached in plaintext on the device
• Weak or missing certificate validation, enabling MitM interception
• Hardcoded API keys/secrets embedded directly in the app binary, extractable via reverse engineering

Secure Infrastructure

Q78. How does server hardening affect web security?

Server hardening removes unnecessary services, closes unused ports, enforces least-privilege file/process permissions, and disables default accounts/credentials — reducing the attack surface a server exposes, so there's simply less for an attacker to find and exploit even before any application-level vulnerability comes into play.

Q79. Explain the importance of patch management in maintaining web security.

A huge share of real-world breaches exploit a known, already-patched vulnerability that simply hadn't been applied yet — timely, systematic patching (of the OS, dependencies, and third-party software) closes off attacks that require zero actual skill to execute once the patch (and its accompanying disclosure) is public.

Q80. What is network segmentation, and how can it improve security for web applications?

Segmentation divides a network into isolated zones (a public-facing web tier, an internal application tier, a database tier with no direct internet access) so a compromise in one segment doesn't automatically grant access to everything else — limiting the blast radius of any single breach.

Q81. Describe how load balancers can be configured to improve web application security.

A load balancer can terminate TLS centrally (simplifying certificate management), integrate a WAF at that single choke point, hide the real backend server topology from direct internet exposure, and apply rate limiting/connection throttling before malicious traffic ever reaches an actual application instance.

Cryptography in Web Security

Q82. What is the difference between symmetric and asymmetric encryption, and how are they used in web security?

TLS actually uses both: asymmetric cryptography to securely establish a shared secret during the handshake (without ever transmitting that secret in the clear), then switches to fast symmetric encryption for the actual bulk data transfer — getting asymmetric crypto's key-distribution benefit without its speed penalty for every byte transferred.

Q83. Explain the role of digital signatures in maintaining web security.

A digital signature proves a piece of data came from a specific holder of a private key and hasn't been altered since — used for verifying software update authenticity, signing JWTs so a server can trust their claims without re-checking a database, and the certificate chain that makes HTTPS's identity guarantee possible at all.

Q84. What is a cryptographic hash function, and where is it used in web security?

A one-way function producing a fixed-size fingerprint of input data, where even a tiny input change produces a completely different output, and reversing it (finding the input from the output) is computationally infeasible — used for password storage (with a purpose-built slow hash, not a fast general one), verifying file/download integrity, and as a building block inside digital signatures and TLS itself.

Q85. How can Public Key Infrastructure (PKI) be used to secure web applications?

PKI is the whole system of certificate authorities, certificates, and cryptographic key pairs that makes HTTPS's identity verification work at internet scale — beyond public HTTPS certificates, organizations use internal PKI for mutual TLS between microservices, code-signing, and client certificate authentication for especially sensitive internal systems.

DevSecOps and Web Security

Q86. How does DevSecOps integrate security into the web development lifecycle?

DevSecOps embeds security checks (static analysis, dependency scanning, secrets detection) directly into the CI/CD pipeline, so vulnerabilities are caught at commit/PR time rather than in a separate, late-stage security review — the security equivalent of shift-left testing, treating security as a continuous automated practice rather than a final gate.

Q87. What are security Information and Event Management (SIEM) systems and their role in web security?

A SIEM aggregates logs and security events from across an entire environment (servers, applications, network devices) into one place, correlating patterns that would be invisible looking at any single log source in isolation — the analytical engine behind most SOC teams' real-time detection capability.

Q88. How can containerization improve web security?

Containers provide process/filesystem isolation between applications sharing the same host, and immutable container images (rebuilt from source rather than patched in place) make it easy to guarantee every deployment runs a known, scanned, up-to-date image — though containerization also introduces its own concerns (image vulnerability scanning, not running containers as root, securing the orchestrator itself).

Q89. Discuss the role of automated security pipelines in web application deployments.

Automated pipeline steps (dependency vulnerability scanning, static analysis, secrets detection, container image scanning) run on every build/PR, blocking a merge or deployment if a serious issue is found — removing the reliance on a human remembering to run a manual security check before every release.

API and Web Service Security

Q90. What are the primary concerns for REST API security?

• Authentication/authorization on every endpoint by default, not opt-in
• Rate limiting to prevent abuse and resource exhaustion
• Input validation on every parameter, exactly as rigorously as a traditional web form
• Never leaking internal implementation details (stack traces, database errors) in API error responses

Q91. How does OAuth 2.0 provide secure delegated access?

Covered above in the OAuth question — scoped, time-limited, revocable access tokens replace sharing a password directly, and the authorization server (not the third-party app) is the only party that ever sees the user's actual credentials.

Q92. What are best practices for securing GraphQL APIs?

• Limit query depth/complexity to prevent a maliciously deeply-nested query from causing a resource-exhaustion denial of service
• Apply authorization at the field/resolver level, not just at the top-level query
• Disable introspection in production if the schema itself shouldn't be publicly discoverable

Q93. How can webhooks be secured to ensure they are not exploited?

const signature = request.headers["x-webhook-signature"];
const expected = hmacSha256(request.rawBody, sharedSecret);
if (!timingSafeEqual(signature, expected)) throw new Error("Invalid signature");

Verify a signature (HMAC of the payload using a shared secret) on every incoming webhook so you can trust it genuinely came from the expected sender — without that, anyone who discovers the webhook URL could send fabricated events your system would otherwise process as legitimate.

Q94. Explain the significance of rate limiting in API security.

Rate limiting caps how many requests a client can make in a given window, mitigating brute-force login attempts, API abuse/scraping, and a class of denial-of-service where a single client (malicious or just buggy) overwhelms the service — a basic, high-leverage control most public-facing APIs need regardless of what else they do.

Web Security Culture and Policy

Q95. How do you foster a culture of security within a web development team?

• Make security everyone's responsibility, not a separate team's problem bolted on at the end
• Regular, practical training (not just an annual compliance video) using real examples relevant to the team's actual stack
• Blameless post-incident reviews, so people report issues honestly instead of hiding them
• Security champions embedded within engineering teams, not just a centralized security function

Q96. What should a web security policy include?

• Acceptable use and access control standards
• Incident response procedures and escalation paths
• Data classification and handling requirements
• Patch management and vulnerability disclosure processes

Q97. Discuss the process of conducting a security risk assessment for web applications.

Identify assets and data flows, enumerate potential threats against each (often via threat modeling), assess likelihood and impact, prioritize by actual risk (not just theoretical severity), and produce a remediation plan — a structured process rather than an unstructured "look for problems" exercise.

Q98. How does change management impact web security?

Uncontrolled, undocumented changes (a manual production config tweak, an unreviewed emergency deploy) are a common source of security misconfiguration — a proper change management process (review, approval, rollback plan) catches security-relevant issues before they ship, the same discipline IaC/CI-CD pipelines bring to infrastructure changes generally.

Q99. Why should a company have an established data breach response protocol?

Without one, the first hours of an actual breach are spent figuring out who's in charge and what to do, instead of actually responding — a pre-established protocol (matching the incident response lifecycle covered earlier) turns a chaotic scramble into an executable plan, and often directly affects legal/regulatory notification deadlines that start ticking the moment a breach is discovered.

Miscellaneous Web Security

Q100. What is the Secure Development Lifecycle (SDL) and its relevance to web security?

SDL integrates security activities into every phase of software development — threat modeling at design time, secure coding standards during implementation, security testing before release, and a response plan for issues found after — rather than treating security as a single audit bolted on right before shipping. It's the umbrella practice that DevSecOps, threat modeling, and secure coding standards all sit underneath.

Test yourself

A quick mock test covering the ground above — the rapid-fire round that often opens a web security interview before the deeper technical discussion.