From 643e4715e7114e381c795d5a98f471b74f39ce61 Mon Sep 17 00:00:00 2001
From: wstgbot <62450690+wstgbot@users.noreply.github.com>
Date: Mon, 12 Oct 2026 13:49:10 +0000
Subject: [PATCH] Publish Latest 2026-10-12

Updates based on OWASP/wstg@9778404
---
 .../06-Session_Management/05-Cross_Site_Request_Forgery.md      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/latest/4-Web_Application_Security_Testing/06-Session_Management/05-Cross_Site_Request_Forgery.md b/latest/4-Web_Application_Security_Testing/06-Session_Management/05-Cross_Site_Request_Forgery.md
index 7e43ba3..a617ef7 100644
--- a/latest/4-Web_Application_Security_Testing/06-Session_Management/05-Cross_Site_Request_Forgery.md
+++ b/latest/4-Web_Application_Security_Testing/06-Session_Management/05-Cross_Site_Request_Forgery.md
@@ -131,7 +131,7 @@ Self-vulnerable applications, i.e. applications that are used both as attack vec
 
 Whether the PoCs above work depends on the session cookie's [`SameSite`](02-Cookies_Attributes.md#samesite-attribute) attribute and the browser's default. See that section for how `SameSite=Lax` treats top-level navigations versus subresource requests.
 
-In short: the `img`-tag PoC is a subresource request, and the auto-submitting form PoC uses `POST` - neither qualifies for the `Lax` top-level-navigation-with-a-safe-method exception, so in a browser that defaults to `Lax` (Chromium-based browsers, since early 2020), the session cookie won't be attached and the PoC as written won't fire. A form using `method="GET"` would still succeed under `Lax`, since that is a top-level `GET` navigation. Note also that [when `Lax` is applied as a default, Chromium-based browsers relax it further for the first two minutes after the cookie is set, still including it on `POST` requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value) - so a POST-based PoC fired immediately after authentication may still succeed.
+In short: the `img`-tag PoC is a subresource request, and the auto-submitting form PoC uses `POST` - neither qualifies for the `Lax` top-level-navigation-with-a-safe-method exception, so in a browser that defaults to `Lax` (Chromium-based browsers, since early 2020), the session cookie won't be attached and the PoC as written won't fire. A form using `method="GET"` would still succeed under `Lax`, since that is a top-level `GET` navigation. Note also that when `Lax` is applied as a default, [Chromium-based browsers relax it further for the first two minutes after the cookie is set](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value), still including it on `POST` requests - so a POST-based PoC fired immediately after authentication may still succeed.
 
 Don't conclude an application is safe from CSRF just because a PoC fails to fire in one browser - check the actual `Set-Cookie` header for the session cookie, and, if needed, retest in a browser that doesn't default to `Lax` (e.g. Firefox) to confirm whether the underlying vulnerability exists.