From 8f4a50109c724caff1c3f4b5e1bda596ee5b456f Mon Sep 17 00:00:00 2001
From: mateofumis <87695536+mateofumis@users.noreply.github.com>
Date: Sun, 26 Jul 2026 11:19:24 -0300
Subject: [PATCH] enhancement of OAuth 2.0 Best Practices section with an
 update

---
 .../0x04e-Testing-Authentication-and-Session-Management.md    | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Document/0x04e-Testing-Authentication-and-Session-Management.md b/Document/0x04e-Testing-Authentication-and-Session-Management.md
index 01aa8215545..68f8bf01330 100644
--- a/Document/0x04e-Testing-Authentication-and-Session-Management.md
+++ b/Document/0x04e-Testing-Authentication-and-Session-Management.md
@@ -237,6 +237,10 @@ Some of the best practices include but are not limited to:
     - Remember that an attacker who has stolen tokens can access their scope and all resources associated with them if the app uses access tokens as bearer tokens with no other way to identify the client.
     - Store refresh tokens in secure local storage; they are long-term credentials.
 
+When implementing OAuth2 in **native apps** that need to interact with social media accounts, the use of embedded user agents such as WebView or WKWebView must always be avoided, because the host app has full control over the embedded view and can record user inputs such as usernames and passwords.
+
+Instead of using _custom schemes_, for example `myapp://callback`, App Links (Android) or Universal Links (iOS) must always be used. If a second app registers the same custom scheme as the legitimate, it could lead the user to a hijack scenario when the malicious app steals the secret code.
+
 ## User Logout
 
 Failing to destroy the server-side session is one of the most common logout functionality implementation errors. This error keeps the session or token alive, even after the user logs out of the application. An attacker who gets valid authentication information can continue to use it and hijack a user's account.