diff --git a/src/pentesting-web/cache-deception/README.md b/src/pentesting-web/cache-deception/README.md
index 3b137c24ff6..56ca0dd3224 100644
--- a/src/pentesting-web/cache-deception/README.md
+++ b/src/pentesting-web/cache-deception/README.md
@@ -461,6 +461,57 @@ Validation checklist
 - Confirm the authenticated header is present on the retargeted request (e.g., in a proxy or via server-side logs) and that the CDN caches the response under the traversed path.
 - From a fresh context (no auth), request the same path and confirm the secret JSON is served from cache.
 
+
+### Authenticated HTML cache entries targeted with query cache busters
+
+Not every WCD requires path confusion or static extensions. A very common variant is: **authenticated HTML response + shared cacheability + attacker-controlled cache key + user-specific secret in the body**.
+
+Typical indicators:
+
+- The authenticated page returns **`X-Cache: MISS`** on first load and **`X-Cache: HIT`** when replayed.
+- **`Cache-Control`** allows shared caching (for example, it lacks **`private`** / **`no-store`**).
+- The HTML source contains **victim-specific data** such as JWTs, CSRF tokens, email addresses, account settings, or bootstrapped session objects inside inline JavaScript.
+
+Minimal validation flow:
+
+1. Authenticate and request a page that should be user-specific (homepages are still interesting if they bootstrap session state).
+2. Replay the exact request in Burp Repeater.
+3. Compare **`X-Cache`**, **`Age`**, and **`Cache-Control`**.
+4. Inspect the cached body, not just the headers: if secrets are embedded in the HTML/JS, another user hitting the same cache key may receive them.
+
+If many users constantly overwrite the shared entry, add an **attacker-chosen query parameter** to isolate the cache key:
+
+```http
+GET /?cacheBuster=1 HTTP/1.1
+Host: target.com
+Cookie: session=<victim-session>
+```
+
+If the cache keys on the full URL, forcing the victim to visit that exact URL stores their authenticated response under a predictable entry that the attacker can later request anonymously. This is especially useful on homepages that are globally cacheable but still inject per-user state into the DOM.
+
+### SameSite=Lax delivery constraints in WCD campaigns
+
+When the victim must seed the cache from an attacker-controlled site, remember that **default `SameSite=Lax` cookies are usually not sent on cross-site subresource requests** such as **`<img>`**, **`<script>`**, or XHR/fetch. Therefore, a payload like the following often primes the cache with an **unauthenticated** response only:
+
+```html
+<img src="https://target.com/?cacheBuster=1">
+```
+
+To seed the cache with the victim's authenticated HTML, use a **top-level navigation** primitive instead, because `SameSite=Lax` still allows cookies on cross-site navigations such as links and many GET redirects:
+
+```html
+<meta http-equiv="refresh" content="0; url=https://target.com/?cacheBuster=1">
+<p>If not redirected, <a href="https://target.com/?cacheBuster=1">open target</a>.</p>
+```
+
+Practical checklist:
+
+- First confirm that the **subresource** version does **not** include cookies.
+- Then switch to a **top-level navigation** and verify that the cacheable response now contains victim-only data.
+- Re-request the exact cache-buster URL from a clean context and confirm the secret is returned from cache.
+
+This turns a noisy, random WCD into a **targeted account-takeover primitive** whenever the cached HTML exposes reusable session material.
+
 ## Automatic Tools
 
 - [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner to find web cache poisoning vulnerabilities in a list of URLs and test multiple injection techniques.
@@ -482,6 +533,7 @@ Validation checklist
 - [CSPT presentation by Maxence Schmitt](https://www.youtube.com/watch?v=O1ZN_OCfNzg)
 - [PortSwigger: Web Cache Deception](https://portswigger.net/web-security/web-cache-deception)
 - [Cache Poisoning Case Studies Part 1: Foundational Attacks Behind a $100K+ Vulnerability Class](https://herish.me/blog/cache-poisoning-case-studies-part-1-foundational-attacks/)
+- [Cracking SameSite for a $2,000 Web Cache Deception](https://medium.com/@tinopreter/cracking-samesite-for-a-2-000-web-cache-deception-746972278412)