diff --git a/pentesting-web/cross-site-websocket-hijacking-cswsh.md b/pentesting-web/cross-site-websocket-hijacking-cswsh.md
index f74cb521e..f3900fdc3 100644
--- a/pentesting-web/cross-site-websocket-hijacking-cswsh.md
+++ b/pentesting-web/cross-site-websocket-hijacking-cswsh.md
@@ -73,6 +73,10 @@ Once the client is trying to connect to you you can use:
 websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v
 ```
 
+## Websockets Enumeration
+
+You can use the **tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **to discover, fingerprint and search for known** **vulnerabilities** in websockets automatically.
+
 ## Cross-site WebSocket hijacking (CSWSH)
 
 Also known as _cross-origin WebSocket hijacking_.\
diff --git a/pentesting-web/oauth-to-account-takeover.md b/pentesting-web/oauth-to-account-takeover.md
index 41d0e9be6..c83f1b78b 100644
--- a/pentesting-web/oauth-to-account-takeover.md
+++ b/pentesting-web/oauth-to-account-takeover.md
@@ -89,6 +89,14 @@ All these parameters are **optional according to the OAuth and OpenID** specific
 
 If you target an OpenID server, the discovery endpoint at **`.well-known/openid-configuration`**sometimes contains parameters such as "_registration\_endpoint_", "_request\_uri\_parameter\_supported_", and "_require\_request\_uri\_registration_". These can help you to find the registration endpoint and other server configuration values.
 
+### XSS in redirect implementation <a href="#bda5" id="bda5"></a>
+
+As mentioned in this bug bounty report [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) it might be possible that the redirect **URL is being reflected in the response** of the server after the user authenticates, being **vulnerable to XSS**. Possible payload to test:
+
+```
+https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
+```
+
 ### CSRF - Improper handling of state parameter <a href="#bda5" id="bda5"></a>
 
 Very often, the **`state` parameter is completely omitted or used in the wrong way**. If a state parameter is **nonexistent**, **or a static value** that never changes, the OAuth flow will very likely be **vulnerable to CSRF**. Sometimes, even if there is a `state` parameter, the **application might not do any validation of the parameter** and an attack will work. The way to exploit this would be to go through the authorization process on your own account, and pause right after authorising. You will then come across a request such as: