Forem: Yuriy Safronnynov

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