diff --git a/network-services-pentesting/pentesting-web/special-http-headers.md b/network-services-pentesting/pentesting-web/special-http-headers.md
index bbfce255..9275af1d 100644
--- a/network-services-pentesting/pentesting-web/special-http-headers.md
+++ b/network-services-pentesting/pentesting-web/special-http-headers.md
@@ -74,6 +74,7 @@ A hop-by-hop header is a header which is designed to be processed and consumed b
 * **`Cache-Control`** indicates if a resource is being cached and when will be the next time the resource will be cached again: `Cache-Control: public, max-age=1800`
 * **`Vary`** is often used in the response to **indicate additional headers** that are treated as **part of the cache key** even if they are normally unkeyed.
 * **`Age`** defines the times in seconds the object has been in the proxy cache.
+* **`Server-Timing: cdn-cache; desc=HIT`** also indicates that a resource was cached
 
 {% content-ref url="../../pentesting-web/cache-deception.md" %}
 [cache-deception.md](../../pentesting-web/cache-deception.md)
diff --git a/pentesting-web/cache-deception.md b/pentesting-web/cache-deception.md
index f79290b2..c5daeca3 100644
--- a/pentesting-web/cache-deception.md
+++ b/pentesting-web/cache-deception.md
@@ -36,9 +36,18 @@ The poisoned response will only be served to users who visit the affected page w
 
 In order to perform a cache poisoning attack you need first to **identify unkeyed inputs** (parameters not needed to appear on the the cached request but that change the returned page), see **how to abuse** this parameter and **get the response cached**.
 
-### Identify and evaluate unkeyed inputs
+### Discovery: Check HTTP headers
 
-You could use [Param Miner](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) to **brute-force parameters and headers** that may be **changing the response of the page**. For example, a page may be using the header `X-Forwarded-For` to indicate the client to load script from there:
+Usually when a response was **stored in the cache** there will be a **header indicating so**, you can check which headers you should pay attention to in this post: [**HTTP Cache headers**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
+
+### Discovery: Caching 400 code
+
+If you are thinking that the response is being stored in a cache, you could try to **send requests with a bad header**, which should be responded with a **status code 400**. Then try to access the request normally and if the **response is a 400 status code** , you know it's vulnerable (and you could even perform a DoS).\
+_Note that sometimes these kind of status code aren't cached so this test will be useless._
+
+### Discovery: Identify and evaluate unkeyed inputs
+
+You could use [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) to **brute-force parameters and headers** that may be **changing the response of the page**. For example, a page may be using the header `X-Forwarded-For` to indicate the client to load script from there:
 
 ```markup
 <script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
@@ -197,7 +206,14 @@ Sending a header containing an illegal character, `\` would cause a cacheable 40
 
 The goal of Cache Deception is to make clients **load resources that are going to be saved by the cache with their sensitive information**.
 
-First of all note that **extensions** such as `.css`, `.js`, `.png` etc are usually **configured** to be **saved** in the **cache.** Therefore, if you access w\_ww.example.com/profile.php/nonexistent.js\_ the cache will probably store the response because it sees the `.js` **extension**. But, if the **application** is **replaying** with the **sensitive** user contents stored in _www.example.com/profile.php_, you can **steal** those contents from other users.
+First of all note that **extensions** such as `.css`, `.js`, `.png` etc are usually **configured** to be **saved** in the **cache.** Therefore, if you access `www.example.com/profile.php/nonexistent.js` the cache will probably store the response because it sees the `.js` **extension**. But, if the **application** is **replaying** with the **sensitive** user contents stored in _www.example.com/profile.php_, you can **steal** those contents from other users.\
+Other things to test:
+
+* _www.example.com/profile.php/.js_
+* _www.example.com/profile.php/.css_
+* _www.example.com/profile.php/test.js_
+* _www.example.com/profile.php/../test.js_
+* _www.example.com/profile.php/%2e%2e/test.js_
 
 Another very clear example can be found in this write-up: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
 In the example it is explained that if you load a non-existent page like _http://www.example.com/home.php/non-existent.css_ the content of _http://www.example.com/home.php_ (**with the users sensitive information**) is going to be returned and the cache server is going to save the result.\