[Golang/CVE] Why Your Playwright Tests Might Fail After Updating gorilla/csrf to Fix CVE-2024-24787

After updating the github.com/gorilla/csrf package in your Go backend from v1.7.2 to v1.7.3, you might suddenly notice that your Playwright tests start failing — specifically with 403 Forbidden responses.

What Changed?

This update addresses a security vulnerability: CVE-2024-24787. It’s a Golang backend issue, not related to WebSocket libraries like ws, despite what some GitHub advisory titles might misleadingly suggest.

In v1.7.3, gorilla/csrf now strictly enforces same-site origin checks using the Origin and Referer headers. If these headers are missing or don’t match the expected host, CSRF validation fails, and the request is blocked with a 403.

Why This Breaks Playwright Tests

Automated browser tests like those written with Playwright may:

Skip setting Origin or Referer

Submit CSRF-protected requests without extracting and including a valid token

As a result, the CSRF middleware in Go rejects the request as a potential attack.

How to Fix It

Update your Playwright tests to behave more like a real browser:

1. Set matching headers

await page.request.post('https://localhost:3000/api/data', {
  headers: {
    'Origin': 'https://localhost:3000',
    'Referer': 'https://localhost:3000/page',
    'X-CSRF-Token': token,
  },
  data: { ... },
});

2. Extract the CSRF token from the page

const token = await page.getAttribute('meta[name="csrf-token"]', 'content');

3. (Optional) Configure your backend to allow trusted origins during local testing

csrf.Protect(key, csrf.Secure(false), csrf.TrustedOrigins([]string{"http://localhost:3000"}))

Don’t Disable CSRF in Production

It’s tempting to loosen CSRF checks in test environments, but be sure your production configs are secure. This CVE fix is important — it protects your users.

If your Playwright tests suddenly started failing with 403 errors after a routine Go package upgrade, the fix to gorilla/csrf for CVE-2024-24787 or CVE-2025-24358 in DockerScout is likely the cause. The good news? A few small changes to your test setup will get everything back on track — securely.