[github-actions]

[agentgateway/agentgateway#4090 + agentgateway/agentgateway#4091](agentgateway/agentgateway#4090 and agentgateway/agentgateway#4091) — CSRF origin handling

Docs versions: standalone/main, kubernetes/main

What changes for users: CSRF validation treats Origin: null as cross-origin on requests without Sec-Fetch-Site, so those requests are rejected unless additionalOrigins includes null. The same-origin fallback compares the Origin host to the request Host and ignores the scheme, which covers TLS-terminating proxy setups.

What the docs now say: The standalone CSRF page now lists the scheme-insensitive same-origin check, the Origin: null rejection, and the additionalOrigins exception. The Kubernetes CSRF guide now says the same for kubernetes/main through a version-gated shared asset.

Not verified: No cluster or local proxy was run; the configuration and request examples are unrun.

How agentgateway-4090 was drafted, and what was not verified

• Code PR: csrf: treat Origin: null as a cross-origin request agentgateway#4090 and csrf: compare only the Origin host, ignoring scheme agentgateway#4091
• Code issue: none linked
• Product: agentgateway (upstream) -> agentgateway/website
• Docs version: standalone/main and kubernetes/main, documented in the development tree
• Category: scoped-edit / pr

Plan, and what changed it

• Planned: Update the CSRF pages that the code-path rule named with the runtime behavior changes from the two pull requests.
• Learned: The work-list clustered #4090 and #4091, and changed-functions.md showed one shared CSRF behavior change; hugo.yaml and version-gates.md showed that the Kubernetes body is a shared asset that needs a main-only gate.
• Did: Updated the standalone main page directly, added gated kubernetes/main content to the shared CSRF asset, and wrote a release-note draft.

Why a documentation change is necessary

The existing CSRF pages already explain same-origin checks and additionalOrigins, but they did not say how the fallback treats schemes or opaque origins. #4090 removes the special case that treated Origin: null as no origin, so a request without Sec-Fetch-Site is rejected unless null is trusted. #4091 changes the same-origin fallback to compare only the Origin host with the request Host, so readers behind a TLS-terminating proxy need the scheme-insensitive rule.

What changed on disk

• assets/agw-docs/pages/security/csrf.md - Added a kubernetes/main-only note about scheme-insensitive host matching and Origin: null, plus the additionalOrigins exception in the field table.
• content/docs/standalone/main/documentation/configuration/security/csrf.md - Added the same behavior to the standalone main CSRF page and updated the allowed/blocked request lists.

How to verify this change

1. In Kubernetes mode, apply the CSRF policy from content/docs/kubernetes/main/documentation/security/csrf.md, then send a state-changing request with Host: www.example.com, Origin: null, and no Sec-Fetch-Site header. The response is 403 Forbidden.
2. Send a state-changing request through the same policy with Host: www.example.com, Origin: https://www.example.com, and no Sec-Fetch-Site header. The response is 200 OK, because the fallback compares only the host.
3. Add null to spec.traffic.csrf.additionalOrigins and repeat the Origin: null request. The response is 200 OK.

What was not verified

The configuration was not applied to a cluster, and the standalone proxy was not run locally. All commands and requests in this report are unrun.

Counterpart sections not drafted:

• kgateway-dev/kgateway.dev:assets/kgw-docs/pages/security/csrf.md has a metrics section, but the dossier does not include CSRF metric names or metric behavior changes for agentgateway.
• kgateway-dev/kgateway.dev:assets/kgw-docs/pages/security/csrf.md has separate Before you begin and Cleanup sections. The Kubernetes page already has prerequisites and cleanup content, and the standalone target is a configuration reference page rather than a full traffic guide.

How the pages were chosen (triage report)

Feature clusters

These pull requests document one feature between them:

Cluster	Pull requests	Product	Why grouped
c5	agentgateway/agentgateway#4090, agentgateway/agentgateway#4091	agentgateway	the same author merged both within 24 hours, they change the same source file, and both are drafted into assets/agw-docs/pages/security/csrf.md, so this looks like one change split across pull requests and separate drafts would conflict

Draft a documentation change

agentgateway/agentgateway#4090 — csrf: treat Origin: null as a cross-origin request

• Product: agentgateway (upstream) → agentgateway/website
• Docs version: standalone/main, kubernetes/main
• Summary (read from the body): Our CSRF policy is a port of Go's net/http CrossOriginProtection, but we added a special case mapping Origin: null to "no Origin", which is then allowed. Go does not do this: only an empty Origin is allowed, and "null" parses with an empty host that never matches the request host, so it is rejected.
• Not tested: no cluster was available, so every command in this diff is unrun

agentgateway/agentgateway#4091 — csrf: compare only the Origin host, ignoring scheme

• Product: agentgateway (upstream) → agentgateway/website
• Docs version: standalone/main, kubernetes/main
• Summary (read from the body): Go's CrossOriginProtection, which this policy is ported from, compares the Origin host against the request Host and deliberately ignores the scheme. We compared the full scheme://authority, so behind a TLS-terminating proxy an old browser's Origin: https://example.com never matched our http://example.com and every state-changing request was rejected.
• Not tested: no cluster was available, so every command in this diff is unrun

Release notes

This pull request also adds its release-note entries:

• content/docs/kubernetes/main/release-notes/release-notes.md: csrf: treat Origin: null as a cross-origin request (fix, under Security)
• content/docs/standalone/main/release-notes/release-notes.md: csrf: treat Origin: null as a cross-origin request (fix, under Security)

Check these release-note links and names. Each note is on its page, but a link may not reach the drafted content there, or a name may belong to the other mode:

• content/docs/kubernetes/main/release-notes/release-notes.md: csrf: treat Origin: null as a cross-origin request agentgateway#4090's note names Origin: null, which content/docs/standalone/main mentions and content/docs/kubernetes/main does not. Check that this tree's readers can set it, or word the note for this mode.
• content/docs/kubernetes/main/release-notes/release-notes.md: csrf: treat Origin: null as a cross-origin request agentgateway#4090's note names Sec-Fetch-Site, which content/docs/standalone/main mentions and content/docs/kubernetes/main does not. Check that this tree's readers can set it, or word the note for this mode.

Draft branch: pr-tracker-draft-agentgateway-4090-plus1

---

Important

The test suite has not run on this pull request. It was opened by github-actions[bot], and GitHub does not start workflows for pull requests opened with the repository's own token. Doc tests, link checking and the static checks are held as action_required until somebody presses Approve and run on the Checks tab. Cloudflare Pages and DCO are GitHub Apps rather than Actions, so those two do run on their own.

Please approve the checks before reviewing the content: an absence of failures here means the tests have not run, not that they passed.

[cloudflare-workers-and-pages]

Deploying agentproxy with    Cloudflare Pages

Latest commit:	9d59db9
Status:	✅  Deploy successful!
Preview URL:	https://6535c671.agentproxy.pages.dev
Branch Preview URL:	https://pr-tracker-draft-agentgatewa-kjj4.agentproxy.pages.dev

View logs