Web Security MCQ 60 Tests With Answers (2026)

Incorrect·A: An attacker injects malicious client-side executable scripts into trusted web pages viewed by other users

XSS (Cross-Site Scripting) exploits a web application's failure to properly sanitize user-supplied content before including it in HTML output. When a victim's browser renders the page, it executes the injected JavaScript in the context of the trusted domain — allowing the attacker to steal session cookies (document.cookie), perform actions on behalf of the user, redirect to phishing pages, or log keystrokes. XSS is prevented by output encoding (HTML entity encoding), Content Security Policy, and input validation.

Incorrect·A: It restricts how a document or script loaded from one origin can interact with a resource from another origin

The Same-Origin Policy (SOP) is a critical browser security mechanism that prevents JavaScript from making cross-origin requests. Two URLs share the same origin only if all three components match: protocol (http vs https), hostname (example.com), and port (80 vs 443). SOP prevents a malicious site from reading your bank's response via JavaScript. CORS is the controlled mechanism to relax SOP when cross-origin access is genuinely needed.

Incorrect·C: By exploiting vulnerabilities in the web application's input fields to manipulate the backend database queries

SQL Injection occurs when user-supplied input is concatenated directly into SQL queries without sanitization or parameterization. An attacker can inject SQL syntax (e.g., ' OR '1'='1) to modify the query's logic, bypass authentication, exfiltrate entire database contents (UNION SELECT), modify or delete data, or in some configurations execute OS commands (xp_cmdshell on MSSQL). Prevention: always use parameterized queries/prepared statements or ORMs — never string concatenate user input into SQL.

Incorrect·D: To inspect, filter, and block malicious Layer 7 HTTP/HTTPS traffic (like XSS or SQLi) directed at a web application

A WAF (Web Application Firewall) operates at OSI Layer 7 (Application layer) and inspects HTTP/HTTPS request and response content — headers, body, cookies, URI parameters — against a ruleset to detect and block web-specific attacks like XSS, SQL injection, CSRF, and SSRF. Unlike traditional network firewalls (Layers 3-4), a WAF understands HTTP semantics. WAFs can be deployed as hardware appliances, software, cloud services (AWS WAF, Cloudflare), or in-application middleware.

Incorrect·A: When an application exposes a reference to an internal implementation object, allowing an attacker to bypass authorization and access other users' data

IDOR is an access control vulnerability where an application uses user-controllable input (like a numeric ID: /invoice?id=1234) to directly reference internal objects (database records, files) without verifying that the requesting user is authorized to access that specific object. An attacker simply increments or changes the ID to access other users' records. Prevention: always perform server-side authorization checks on every data access — verify the requesting user owns/is permitted to access the specific object being requested.

Incorrect·B: Trick a user's browser into executing an unwanted, authenticated action on a web application where they are currently logged in

CSRF (Cross-Site Request Forgery) exploits the web browser's automatic cookie attachment behavior: when a victim visits a malicious page, that page sends a forged HTTP request to a site where the victim is already authenticated (e.g., /transfer?to=attacker&amount=5000 on their bank). The browser automatically attaches the victim's session cookie, making the server believe the request is legitimate. Prevention: anti-CSRF synchronizer tokens, SameSite=Strict/Lax cookie attribute, and custom request headers (X-Requested-With).

Incorrect·A: To mitigate XSS and data injection attacks by strictly defining which dynamic resources and scripts the browser is allowed to load

Content Security Policy (CSP) is an HTTP response header that instructs the browser which sources of content are trusted. A strict CSP (e.g., script-src 'self') prevents the browser from executing any inline scripts or scripts from external domains, effectively breaking XSS payloads even if they are injected into the page. CSP also prevents clickjacking (frame-ancestors directive), mixed content, and unauthorized data exfiltration (connect-src, form-action). CSP is one of the most powerful mitigations against client-side attacks.

Incorrect·D: It prevents client-side scripts (like JavaScript) from accessing the cookie, mitigating the risk of XSS token theft

The HttpOnly cookie attribute instructs the browser not to expose the cookie to client-side JavaScript (document.cookie is blocked for HttpOnly cookies). This is a critical XSS mitigation for session cookies: even if an attacker successfully injects a JavaScript payload, they cannot steal the session token because it is inaccessible via JavaScript. The Secure flag (separate attribute) ensures the cookie is only sent over HTTPS. Both HttpOnly and Secure should be set on all session cookies.

Incorrect·B: It guarantees the cookie is only transmitted over secure, encrypted HTTPS connections, preventing interception

The Secure cookie attribute prevents the browser from sending the cookie over unencrypted HTTP connections — the cookie is transmitted only when the connection uses HTTPS. Without Secure, an SSL-stripping attack (where an attacker downgrades the connection from HTTPS to HTTP) could cause the browser to transmit session cookies in cleartext, exposing them to network interception. Secure should always be set for session cookies alongside HttpOnly and SameSite=Strict.

Incorrect·C: A vulnerability that allows an attacker to read arbitrary files on the server (outside the web root) by manipulating file paths with ../ sequences

Directory (Path) Traversal exploits insufficient input validation when user-supplied file path parameters are used to construct filesystem paths. By injecting ../ sequences (which navigate up a directory level), an attacker can escape the web root directory and read sensitive server files: ../../../etc/passwd (Linux passwords), ../../../../windows/system32/drivers/etc/hosts, or application configuration files containing database credentials. Prevention: validate and canonicalize file paths, use whitelists, and never accept user input to construct file system paths directly.

Incorrect·C: Authentication verifies who the user is; Authorization verifies what the user is allowed to do or access

Authentication (AuthN) answers "Who are you?" — verifying identity via credentials (password, MFA, certificate). Authorization (AuthZ) answers "What can you do?" — determining what resources and actions the authenticated identity is permitted to access. In web security, IDOR and Broken Access Control vulnerabilities are authorization failures; credential stuffing and brute force attacks are authentication attacks. Identity providers handle AuthN; RBAC/ABAC policies handle AuthZ. These must be implemented separately and correctly.

Incorrect·D: To safely relax the Same-Origin Policy and specify exactly which external domains are permitted to access its resources

CORS is a W3C mechanism that uses HTTP headers to allow servers to specify which foreign origins can make cross-origin requests. The server sends Access-Control-Allow-Origin headers indicating permitted origins. CORS enables legitimate cross-origin API calls (e.g., a React app on app.example.com calling api.example.com). CORS misconfiguration — setting Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true — is a critical vulnerability that allows any malicious site to read authenticated data from the API.

Incorrect·B: An attacker intercepting or stealing a valid session token (like a cookie) to impersonate an authenticated user

Session Hijacking occurs when an attacker obtains a valid session token (typically from a session cookie) and uses it to impersonate the legitimate authenticated user — bypassing authentication entirely. Vectors: XSS (stealing cookies via document.cookie if HttpOnly is absent), network sniffing on unencrypted HTTP, predictable session IDs, MITM attacks. Mitigations: HttpOnly + Secure + SameSite cookies, HTTPS everywhere, short session timeouts, session token regeneration after login.

Incorrect·B: Open Worldwide Application Security Project

OWASP (Open Worldwide Application Security Project) is a nonprofit foundation dedicated to improving software security. It produces the globally recognized OWASP Top 10 — a regularly updated list of the most critical web application security risks (e.g., Injection, Broken Access Control, Cryptographic Failures, XSS, SSRF). OWASP also produces the ASVS (Application Security Verification Standard), WebGoat (training app), ZAP (Zed Attack Proxy), and the Cheat Sheet Series for developers.

Incorrect·A: A malicious script uploaded to a compromised web server that grants the attacker remote administrative control

A web shell is a malicious script (PHP, ASP, JSP, etc.) uploaded to a compromised web server — usually via unrestricted file upload, remote file inclusion, or code execution vulnerabilities. Once installed, it provides the attacker with a browser-accessible backdoor to execute OS commands, browse the file system, exfiltrate data, and pivot to internal networks. Detection: file integrity monitoring, WAF rules detecting shell command patterns, and monitoring for unexpected outbound connections.

Incorrect·D: Because unvalidated or unsanitized user input is the root cause of injection attacks (like SQLi and XSS)

The majority of web application vulnerabilities share a single root cause: trusting and unsafely processing user-controlled input. Input validation (rejecting input that does not conform to expected format/length/type), input sanitization (removing or escaping dangerous characters), and output encoding (encoding data before rendering it in HTML/SQL/commands) together form the defense-in-depth against injection attacks. The OWASP "Injection" category and "XSS" category are both fundamentally input handling failures.

Incorrect·B: Tricking a user into clicking a deceptive, invisible, or disguised element on a webpage (often using transparent iframes) to execute unintended actions

Clickjacking embeds a target website in a transparent iframe layered over a deceptive decoy page. The victim believes they are clicking on the visible decoy (e.g., a "Win a Prize!" button), but they are actually clicking on an invisible element of the target site (e.g., "Confirm Purchase" or "Enable Camera"). Prevention: X-Frame-Options: DENY or SAMEORIGIN header, Content-Security-Policy frame-ancestors directive. These instruct browsers to refuse iframe embedding of the protected page.

Incorrect·B: To prevent brute-force attacks, credential stuffing, and DoS attacks by restricting the number of requests a client can make in a given timeframe

API Rate Limiting restricts how many requests a client (identified by IP, API key, or user ID) can make within a defined time window. This prevents: brute-force password attacks (requiring millions of login attempts), credential stuffing (replaying breached credentials at high speed), enumeration attacks (scraping all user records via IDOR), and volumetric DoS attacks. HTTP 429 Too Many Requests is returned when the limit is exceeded. Exponential backoff with lockout further frustrates automated attack tools.

Incorrect·A: An attacker secretly intercepting, reading, and potentially altering the communications between a client and a server

In a MitM (Man-in-the-Middle) attack, the attacker positions themselves between a client and server, secretly relaying and potentially modifying traffic. The victim believes they have a direct connection to the legitimate server. Vectors: ARP spoofing on LAN, rogue Wi-Fi access points, SSL stripping attacks. Defenses: HTTPS (TLS), HSTS (HTTP Strict Transport Security), certificate pinning, mutual TLS (mTLS), and public key infrastructure (PKI) validation.

Incorrect·D: Applying an e-commerce discount code multiple times recursively to force the cart total below zero

Business Logic vulnerabilities exploit flaws in the designed workflow of an application rather than technical implementation errors. They cannot be detected by generic scanners because they require understanding intended business rules. Examples: applying the same discount code multiple times, transferring negative amounts, manipulating price parameters in checkout, bypassing multi-step workflows (directly POSTing to a final step), or race conditions in limited-quantity purchases. Prevention requires deep testing of all state transitions and business rule enforcement on the server side.

Incorrect·C: Exploiting a poorly configured XML parser to read arbitrary local files, interact with internal networks, or execute SSRF via malicious entity references

XXE (XML External Entity) Injection targets XML parsers that support external entity resolution. An attacker submits crafted XML containing external entity declarations (e.g., <!ENTITY xxe SYSTEM "file:///etc/passwd">) and references them in the document; the parser fetches and returns the referenced content. Impact: read arbitrary local files (credentials, config files), perform SSRF against internal systems, cause DoS via "Billion Laughs" entity expansion. Prevention: disable DTD processing and external entity resolution in XML parsers.

Incorrect·A: The attacker tricks the web application backend server into making HTTP requests to an arbitrary domain or internal, protected resource on the attacker's behalf

SSRF (Server-Side Request Forgery) exploits server-side functionality that fetches remote resources (URL fetcher, webhook, PDF generator, image downloader). An attacker supplies a malicious URL pointing to an internal resource the server can reach but the attacker cannot directly: http://169.254.169.254/latest/meta-data/ (AWS IMDSv1 metadata service), internal APIs, or other backend systems behind firewalls. This is how the Capital One breach occurred — SSRF via AWS metadata service exposed IAM credentials. IMDSv2 with session tokens mitigates this.

Incorrect·B: Header, Payload, Signature

A JWT consists of three Base64url-encoded parts separated by dots (xxxxx.yyyyy.zzzzz): (1) Header — specifies the token type and signing algorithm (e.g., {"alg":"HS256","typ":"JWT"}); (2) Payload — contains claims (assertions about the user and metadata: sub, exp, iat, roles); (3) Signature — created by the server signing the encoded Header + Payload with a secret/private key, used to verify the token hasn't been tampered with. JWTs are commonly used as Bearer tokens in Authorization headers.

Incorrect·C: The application accepts tokens where the "alg" header has been maliciously changed to "none", allowing the attacker to bypass the signature verification entirely

The "alg:none" attack exploits JWT libraries that accept tokens with no signature when alg is set to "none". An attacker decodes a legitimate JWT, modifies the payload (escalating privileges), sets alg to "none", removes the signature, and submits it. A vulnerable library skips verification because alg:none means "no signature verification needed." Prevention: explicitly whitelist accepted algorithms in the JWT library configuration, never accept alg:none, and prefer asymmetric algorithms (RS256, ES256) over symmetric (HS256) for scalability.

Incorrect·A: Exploiting discrepancies in how front-end proxies and back-end servers parse conflicting Content-Length and Transfer-Encoding headers, allowing attackers to "smuggle" hidden requests

HTTP Request Smuggling exploits ambiguity between the Content-Length and Transfer-Encoding: chunked headers. When a front-end proxy and back-end server interpret which header takes precedence differently, an attacker can craft a request that the proxy treats as one full request but the back-end treats as two — effectively prepending attacker-controlled content to the next legitimate user's request. This enables cache poisoning, WAF bypass, credential hijacking, and response splitting. Discovered and popularized by James Kettle (PortSwigger).

Incorrect·B: Untrusted, serialized data is instantiated into objects without validation, which can be manipulated by an attacker to achieve Remote Code Execution (RCE)

Insecure Deserialization (OWASP A08:2021) occurs when applications deserialize objects from untrusted sources (cookies, headers, API parameters, file uploads) without first validating their integrity. Attackers craft malicious serialized payloads that, when deserialized, instantiate or manipulate objects in ways that trigger gadget chains, leading to Remote Code Execution, privilege escalation, or data tampering. Languages with complex serialization ecosystems (Java, PHP, Python pickle, .NET) are particularly vulnerable. Prevention: avoid deserializing untrusted data; if unavoidable, use integrity checks (digital signatures) before deserialization.

Incorrect·C: The vulnerability exists entirely in the client-side JavaScript modifying the Document Object Model; the malicious payload never actually reaches the backend server

DOM-based XSS occurs when vulnerable client-side JavaScript reads attacker-controlled data (hash, URL parameter, referrer, postMessage) and writes it unsafely to the DOM (innerHTML, document.write, eval) — entirely on the client side, with no server involvement. This makes DOM XSS invisible to server-side WAFs and input validation. Reflected XSS has the server echo unsanitized input; Stored XSS persists the payload in the database. DOM XSS requires code review of client-side JavaScript source sinks and sources to detect.

Incorrect·A: It securely authenticates the user and issues access tokens to the client application

In OAuth 2.0, four roles interact: Resource Owner (the user), Client (third-party app requesting access), Resource Server (API hosting protected data), and Authorization Server (the trusted identity provider — Google, GitHub, Okta — that authenticates the user and issues access tokens). The client redirects the user to the Authorization Server, which authenticates them and returns an authorization code; the client exchanges this for an access token; the client uses the access token to call the Resource Server API. OAuth flaws (open redirect, state parameter missing, token leakage) are a rich source of real-world vulnerabilities.

Incorrect·B: When a DNS record points to a de-provisioned external service (like AWS S3 or GitHub Pages), allowing an attacker to claim that service space and hijack the subdomain

Subdomain Takeover occurs when a DNS CNAME record (e.g., staging.example.com CNAME exampleapp.azurewebsites.net) continues to exist after the external service it points to has been deprovisioned. An attacker claims the now-available external service slot (registers the same Azure app name, claims the S3 bucket name), serving malicious content from the legitimate subdomain. This enables cookie theft (since cookies are scoped to the domain), phishing under a trusted brand, and CSP bypass. Prevention: remove stale DNS records when deprovisioning external services.

Incorrect·B: It instructs the browser that the website must only be accessed using secure HTTPS connections, preventing SSL-stripping and downgrade attacks

HSTS (HTTP Strict Transport Security) is an HTTP response header (Strict-Transport-Security: max-age=31536000; includeSubDomains; preload) that instructs the browser to always use HTTPS for the domain, refusing any HTTP connection — even if the user manually types http:// or follows an HTTP link. This prevents SSL-stripping attacks (where a MitM downgrades the connection before the TLS handshake). The preload directive submits the domain to browser-maintained HSTS preload lists, offering protection on first visit.

Incorrect·D: Injecting native template syntax (e.g., Jinja2, Twig) into user input, which is then unsafely evaluated by the server, often leading to Remote Code Execution

SSTI occurs when a web application embeds user-supplied input directly into a server-side template that is then rendered by a template engine. Attackers inject template-native expressions ({{7*7}} in Jinja2, ${7*7} in Freemarker) which the engine evaluates — often with access to internal object hierarchies that allow OS command execution. SSTI is frequently mistaken for XSS during initial testing. It is identified by template-specific payloads that return evaluated results (e.g., returning 49 for {{7*7}}). Prevention: sandbox template contexts, never pass user input as template code, use template engines with sandboxing.

Incorrect·B: It allows attackers to craft highly credible phishing links or steal OAuth access tokens by redirecting legitimate authentication flows to a malicious domain

An Open Redirect occurs when an application uses unvalidated user-controlled input to construct a redirect URL: /redirect?url=https://evil.com. Attackers use the trusted domain as a redirect wrapper, making phishing URLs highly credible (https://trusted.com/login?next=https://evil.com/steal-token). More critically, Open Redirects can be chained with OAuth flows to steal authorization codes: an attacker registers a redirect_uri pointing to the open redirect endpoint, causing the authorization server to send the code to the attacker's site. Prevention: whitelist permitted redirect destinations.

Incorrect·C: By using Anti-CSRF synchronizer tokens or implementing strict SameSite cookie attributes

CSRF mitigation strategies: (1) Synchronizer Token Pattern — embed a random, secret, per-session CSRF token in forms/headers that the server validates on submission; (2) SameSite=Strict cookie attribute — prevents cookies from being sent with cross-origin requests, blocking CSRF at the browser level without server-side tokens; (3) Double Submit Cookie — send the same random value in a cookie and a hidden form field, verifying they match. For stateless SPAs using Authorization: Bearer header instead of cookies, CSRF is inherently prevented because browsers do not auto-attach custom headers to cross-origin requests.

Incorrect·C: The application does not return database errors or data directly to the screen; the attacker must infer information by asking boolean true/false questions or measuring time delays

Blind SQLi is used when an application is vulnerable to injection but does not display query results or error messages to the user. Two subtypes: (1) Boolean-based Blind — attacker injects conditions that change the application's behavior (returns different page for true vs false), extracting data bit-by-bit through binary search; (2) Time-based Blind — injects time-delay functions (SLEEP(5), WAITFOR DELAY) and measures response time to infer truth values. Both are significantly slower than in-band injection but equally impactful. SQLMap automates both.

Incorrect·B: Setting Access-Control-Allow-Origin: * in combination with Access-Control-Allow-Credentials: true, allowing any malicious site to read sensitive authenticated data

The most critical CORS misconfiguration is reflecting the Origin header as ACAO (Access-Control-Allow-Origin) with ACAC: true (Access-Control-Allow-Credentials: true). This allows any attacker-controlled site to make credentialed cross-origin requests to the API and read the responses — including session data and personal information. Note: ACAO: * (wildcard) combined with ACAC: true is explicitly invalid per the spec, but some servers reflect the Origin header dynamically, effectively granting any origin full credentialed access.

Incorrect·B: JavaScript (Node.js/Client-side)

Prototype Pollution is a JavaScript-specific vulnerability where an attacker can inject properties into JavaScript's base Object.prototype using specially crafted property names like __proto__, constructor, or prototype in JSON payloads or query parameters. Since all JavaScript objects inherit from Object.prototype, polluting it affects all objects in the runtime. Impact ranges from property injection for logic bypass (e.g., setting isAdmin: true on prototype) to Remote Code Execution in Node.js via gadget chains in popular libraries (lodash merge, jQuery extend were historically vulnerable).

Incorrect·A: To provide a fake piece of data or credential that alerts defenders immediately if it is ever accessed, indicating a breach or unauthorized access

A Canary Token (honeytoken) is a deliberate decoy resource — a fake API key, credential, URL, or file — planted in locations an attacker would access if they had compromised the system (source code, config files, backups). When accessed, the token fires an alert to defenders with the attacker's IP, time, and access context. Unlike other detection mechanisms, honeytokens have zero legitimate uses, meaning any access is unambiguously malicious. Tools like CanaryTokens.org provide easy deployment. They are effective for detecting insider threats and external breaches that standard logging might miss.

Incorrect·B: Supplying multiple parameters with the exact same name in an HTTP request to manipulate backend application logic or bypass WAF rules

HTTP Parameter Pollution (HPP) exploits inconsistent behavior between HTTP frameworks and WAFs when multiple parameters share the same name (e.g., ?role=user&role=admin). Different frameworks handle duplicates differently: PHP/Apache uses the last value, ASP.NET uses the first, Express.js creates an array. Attackers use this to: bypass WAF rules (split a malicious payload across duplicate parameters so each half appears benign), override server-side parameter values, and exploit inconsistencies between a WAF and the backend application. Prevention: define and enforce explicit parameter handling policies.

Incorrect·C: WebSockets do not strictly enforce the Same-Origin Policy (SOP) by default, making them highly vulnerable to Cross-Site WebSocket Hijacking (CSWSH) if origin headers aren't validated

WebSockets upgrade an HTTP connection to a persistent bidirectional channel (ws:// or wss://). Unlike XMLHttpRequest, the browser does NOT enforce the Same-Origin Policy for WebSocket connections — it will send cookies with WebSocket handshake requests to any origin. This enables Cross-Site WebSocket Hijacking (CSWSH): a malicious page opens a WebSocket connection to the victim's application, which attaches session cookies, allowing the attacker to receive real-time data. Prevention: always validate the Origin header in the WebSocket handshake, and require CSRF tokens.

Incorrect·B: Using massive lists of compromised username/password pairs from previous data breaches to automate login attempts on other web applications

Credential stuffing exploits password reuse: attackers obtain breached credential databases (billions of username:password pairs from past breaches — available on dark web marketplaces) and use automation tools (Sentry MBA, OpenBullet) to test these credentials against other services at high speed. Because many users reuse passwords across sites, this succeeds at scale despite no brute-forcing of the target site itself. Defenses: MFA (most effective), bot detection (CAPTCHA, fingerprinting), rate limiting/IP blocking, breached password detection (HaveIBeenPwned API), and behavioral analytics.