OWASP · sydseter · Mar 23, 2026 · Mar 23, 2026 · Mar 23, 2026 · Mar 23, 2026
@@ -32,6 +32,6 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 2. Enforce the use of signature verification for the distribution of executable code and packages.
 3. Consider using anti reverse-engineering techniques. Implement code obfuscation techniques to prevent easy decompilation and understanding of business logic in distributed binaries.
 4. Avoid embedding secrets in the source code. Instead, use secure methods for managing and accessing credentials and keys.
-5. Conduct regular security reviews and audits of source code management practices
+5. Conduct regular security reviews and audits of source code management practices.
 
 For detailed advice on how to mitigate threats related to the card, see the [ASVS and OWASP Developer Guide requirements ](#mapping 'ASVS and OWASP Developer Guide requirements [internal]') in the table below.
@@ -33,5 +33,6 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 1. Implement comprehensive logging of all user activities within the application, capturing details such as timestamps, user IDs, and the nature of the actions.
 2. Ensure that all actions are attributable to individual users by maintaining secure and unique user identification mechanisms.
 3. Develop robust audit trails that provide a clear and detailed history of user actions for accountability and forensic analysis.
+4. Ensure that logs are securely transmitted to a logically separate system for analysis, detection, alerting, and escalation, and that they are protected from unauthorized access and modification.
 
 For detailed advice on how to mitigate threats related to the card, see the [ASVS and OWASP Developer Guide requirements ](#mapping 'ASVS and OWASP Developer Guide requirements [internal]') in the table below.
@@ -18,9 +18,10 @@ The primary STRIDE category is **Spoofing**.
 
 This scenario is about exploiting trust for malicious gain, typically referred to in STRIDE as **Spoofing**, because Larry pretends to be the trusted application or uses its trusted identity to deceive others.
 
+
 ### What can go wrong?
 
-Such manipulation can lead to significant breaches of user trust, unauthorized access to sensitive information, and exploitation of interconnected systems. Abuse of trust attacks include: Clickjacking, Phishing, Pharming, SSL downgrade/misconfiguration.
+Such manipulation can lead to significant breaches of user trust, unauthorized access to sensitive information, and exploitation of interconnected systems. Abuse of trust attacks include: Clickjacking, Phishing, Pharming, SSL downgrade/misconfiguration, auth code interception attacks, mix-up attacks, and session- and token-replay.
 
 For more things that can go wrong, see the [Common Attack Patterns related to this card](#mapping 'Common Attack Patterns related to this card [internal]') in the table below.
 
@@ -30,5 +31,6 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 2. Educate users about the risks of phishing and other trust exploitation tactics. 
 3. Monitor and control how the application’s APIs and services interact with other systems, ensuring secure and verified connections.
 4. Establish strict guidelines and security protocols for third-party applications or services that integrate with the application.
+5. Implement and properly configure identity managment to ensure authentication and authorization flows and authorization tokens are properly secured to mitigate against unauthorized access and exploitation of interconnected systems. 
 
 For detailed advice on how to mitigate threats related to the card, see the [ASVS and OWASP Developer Guide requirements ](#mapping 'ASVS and OWASP Developer Guide requirements [internal]') in the table below.
@@ -24,7 +24,7 @@ The STRIDE category applicable here is **Repudiation**.
 
 ### What can go wrong?
 
-Inadequate logging and auditing can lead to significant gaps in security oversight, hindering the ability to detect, investigate, and respond to unauthorized activities.
+Inadequate logging and auditing can lead to significant gaps in security oversight, hindering the ability to detect, investigate, and respond to unauthorized activities. It increases the risk of identity theft, insider threats, advanced persistent threats, and replay attacks going on unnotified.
 
 For more things that can go wrong, see the [Common Attack Patterns related to this card](#mapping 'Common Attack Patterns related to this card [internal]') in the table below.
 

@@ -34,7 +34,7 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 
 ### What are we going to do about it?
 
-1. Regularly update all frameworks, libraries, and components to their latest, secure versions.
+1. Regularly update all frameworks, libraries, and components to their latest, secure versions and ensure their versions are pinned.
 2. Conduct thorough security reviews and vulnerability assessments of all in-house, outsourced, and open-source code used within the application.
 3. Monitor security advisories for any components used within the application and respond swiftly to vulnerability disclosures.
 4. Establish a robust security protocol for integrating and maintaining external software components.

@@ -6,6 +6,8 @@ Picture a scenario where Romain accesses and modifies unencrypted data, either i
 
 2. **Data Exposed in Communication:** Personal and commercially-sensitive data is transmitted without encryption, either within the application or in interactions with external systems.
 
+3. **Data is not properly signed or hashed:** Personal and commercially-sensitive data is not properly signed using a HMAC, a asymetric key, or both meaning that the data can be modified in transit.
+
 ### Example
 
 Romain targets an application that handles sensitive user data but fails to encrypt this data while in use or during internal processing. He exploits this by accessing the application’s memory, where he finds unencrypted credentials and session identifiers. Additionally, Romain intercepts data being transmitted between the application and external systems, such as payment gateways, as it is sent without proper encryption, allowing him to read and modify sensitive information during transit.
@@ -27,8 +29,8 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 
 ### What are we going to do about it?
 
-1. Implement encryption for sensitive data while it is in memory and during processing within the application.
-2. Ensure that all data communications, both internal and external, are secured with robust encryption methods.
+1. Implement proper encryption for sensitive data while it is in memory, in transit, and during processing within the application according to the latest recommendations on crypographic operations.
+2. Ensure that all data communications, both internal and external, are secured with robust and recommended encryption methods using only approved and recommended cryptographic algorithms and modes of operation.
 3. Regularly review and update encryption practices to cover data in use, in transit, and during communications with external systems.
 
 For detailed advice on how to mitigate threats related to the card, see the [ASVS and OWASP Developer Guide requirements ](#mapping 'ASVS and OWASP Developer Guide requirements [internal]') in the table below.
@@ -36,5 +36,9 @@ Configuration best practice guidance needs to be reviewed periodically, vulnerab
 2. Use valid and trusted certificates for encrypted communications to prevent man-in-the-middle attacks.
 3. Prevent the possibility of downgrading encrypted connections to weaker or unencrypted states.
 4. Regularly review and update the cryptographic setup to address new vulnerabilities and maintain strong security.
+5. Ensure digital signatures and HMACs, as part of data authentication or data integrity are collision resistant and have appropriate bit-lengths.
+6. All random numbers and strings which are intended to be non-guessable must be generated using a cryptographically secure pseudo-random number generator (CSPRNG) and have at least 128 bits of entropy.
+7. Only use the latest recommended versions of TLS, such as TLS 1.2 and TLS 1.3 and that it's used for all communication within and external to the application.
+9. Log and monitor security events such as backend TLS and encryption failures.
 
 For detailed advice on how to mitigate threats related to the card, see the [ASVS and OWASP Developer Guide requirements ](#mapping 'ASVS and OWASP Developer Guide requirements [internal]') in the table below.
@@ -30,5 +30,9 @@ For more things that can go wrong, see the [Common Attack Patterns related to th
 1. Implement robust encryption for sensitive data storage, ensuring that even if data is accessed, it remains unintelligible and secure.
 2. Use secure hashing algorithms, particularly for storing passwords, to prevent them from being reverted to their original form.
 3. Regularly review and update encryption and hashing methods to adhere to current best practices and standards.
+4. Ensure digital signatures and HMACs, as part of data authentication or data integrity are collision resistant and have appropriate bit-lengths.
+5. All random numbers and strings which are intended to be non-guessable must be generated using a cryptographically secure pseudo-random number generator (CSPRNG) and have at least 128 bits of entropy.
+6. Only use the latest recommended versions of TLS, such as TLS 1.2 and TLS 1.3 and that it's used for all communication within and external to the application.
+7. Log and monitor security events such as backend TLS and encryption failures.
 
 For detailed advice on how to mitigate threats related to the card, see the [ASVS and OWASP Developer Guide requirements ](#mapping 'ASVS and OWASP Developer Guide requirements [internal]') in the table below.