diff --git a/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.md b/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.md
index 7b3f5afd01..82af5bb1a4 100644
--- a/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.md
+++ b/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.md
@@ -27,7 +27,7 @@ The invocation of third-party JS code in a web application requires consideratio
 
 ### Risk 1: Loss of control over changes to the client application
 
-This risk arises from the fact that there is usually no guaranty that the code hosted at the third-party will remain the same as seen from the developers and testers: new features may be pushed in the third-party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.
+This risk arises from the fact that there is usually no guarantee that the code hosted at the third-party will remain the same as seen from the developers and testers: new features may be pushed in the third-party code at any time, thus potentially breaking the interface or data-flows and exposing the availability of your application to its users/customers.
 
 Typical defenses include, but are not restricted to: in-house script mirroring (to prevent alterations by 3rd parties), sub-resource integrity (to enable browser-level interception) and secure transmission of the third-party code (to prevent modifications while in-transit). See below for more details.