Which Web Vulnerability Is Exploited by an XML External Entity DTD Payload?
Which of the following web vulnerabilities would an attacker be attempting to exploit if they delivered the following input? - 
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The question tests recognition of a DTD ENTITY/SYSTEM declaration as XXE, and the trap is assuming any injected payload that references /etc/passwd is SQL injection.
The payload is an XML DTD that declares an external entity resolving a local file, the signature of an XML External Entity (XXE) attack. This page confirms option B and explains why SQLi, XSS, and IDOR do not match the input.
The most common wrong pick is SQLi (A) because /etc/passwd is a frequent SQL-injection file-read target; however, the DTD ENTITY and SYSTEM syntax is XML parser abuse, not a database query.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The screenshot shows an XML document type definition that declares an external entity named trustme with a SYSTEM identifier pointing at a local file such as /etc/passwd. When a vulnerable XML parser processes this document, it resolves the entity and substitutes the file's contents into the parsed output, which is the textbook definition of XML External Entity (XXE) injection. The attack abuses DTD entity resolution rather than a database query, a browser script context, or an object identifier. Therefore option B is the only match for the delivered input, and the community's consistent B votes reflect that reading.Why the Other Options Are Wrong
SQLi (A) requires SQL syntax or query-structure manipulation, and although /etc/passwd is a common file-read target in database attacks, the payload here contains no SQL statement or database delimiter. The option shown as XXS (C) is presumably a typo for XSS, but cross-site scripting needs script execution in a victim's browser—there is no <script> tag or event handler in the DTD. IDOR (D) is an authorization flaw where an attacker changes an object reference to access another user's record; the payload does not reference a user-controlled object identifier. None of these mechanisms explains the ENTITY and SYSTEM declarations visible in the input.Community Comment Notes
As qtygbapjpesdayazko notes, the keyword here is "XML External Entity Injection (XXE)", which directly names the DTD entity mechanism in the payload. shaody explains that the issue arises when a "misconfigured XML parser allows applications to parse XML input from an unreliable source", capturing the root cause rather than just the label. g_man_rap reads the image as declaring an "external entity called trustme with a system identifier pointing to a local file", which matches the /etc/passwd file-read pattern. insaniunt's page reference also points to XXE, and no commenter argues for SQLi, XSS, or IDOR.Official Reference
Exam Strategy
When you see DTD, ENTITY, or SYSTEM keywords in a payload, map them to XML External Entity injection before considering SQLi or XSS. The file path /etc/passwd is a decoy that can also appear in SQLi, so focus on the surrounding syntax rather than the target file. Eliminate IDOR early because it requires an object identifier and an authorization boundary.
Frequently Asked Questions
Why is XXE the answer instead of SQLi for this DTD input?
The payload uses an XML ENTITY/SYSTEM declaration, so the parser resolves a local file; SQLi would require SQL syntax in a database query, which is absent.
Does the /etc/passwd path in the payload make this IDOR?
No. IDOR changes an object identifier to bypass authorization; reading /etc/passwd through a DTD entity is XXE, not an access-control flaw.