Probely · nunoloureiro · Mar 6, 2026 · Mar 6, 2026
@@ -5,6 +5,7 @@ cvss-score: 5.3
 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
 cwe-id: CWE-550
 cwe-name: Server-generated Error Message Containing Sensitive Information
+correlatable: SAST
 compliance:
   HIPAA: 164.306(a)
   ISO 27001: A.5.33, A.5.34, A.8.4, A.8.9, A.8.12, A.8.25

@@ -5,6 +5,7 @@ cvss-score: 5.3
 cvss-vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
 cwe-id: CWE-489
 cwe-name: Active Debug Code
+correlatable: SAST
 compliance:
   HIPAA: 164.306(a), 164.312(a)(1), 164.312(d)
   ISO 27001: A.5.33, A.5.34, A.8.4, A.8.9, A.8.12, A.8.15, A.8.25
@@ -14,28 +15,28 @@ compliance:
 
 ---            
 
-The ASP.NET debug feature is useful for debugging ASP.NET web applications, and even be used for remote debugging. This feature can reveal sensitive information about the internals of the application, such as code snippets, environment variables, security keys, etc. All of this can be used by an attacker to increase the likelihood of an successful attack.
-
+The ASP.NET debug feature is useful for debugging ASP.NET web applications, and even be used for remote debugging. This feature can reveal sensitive information about the internals of the application, such as code snippets, environment variables, security keys, etc. All of this can be used by an attacker to increase the likelihood of an successful attack.
+
 This debug feature should not be enabled in a production environment.
 
 ## How to fix
 
 {% tabs aspnet-debugging-enabled %}
 {% tab aspnet-debugging-enabled generic %}
-ASP.NET debugging is a feature of the ASP.NET framework, configured in the `web.config` file. To disable it, you need to edit the `web.config` file and change the `debug` flag within your `compilation` directive to `false`:
-
-```
-    <configuration>  
-        <system.web>  
-            <compilation  
-                debug="false"  
-                ...  
-            >  
-            ...  
-            </compilation>  
-        </system.web>  
-    </configuration>  
-
+ASP.NET debugging is a feature of the ASP.NET framework, configured in the `web.config` file. To disable it, you need to edit the `web.config` file and change the `debug` flag within your `compilation` directive to `false`:
+
+```
+    <configuration>  
+        <system.web>  
+            <compilation  
+                debug="false"  
+                ...  
+            >  
+            ...  
+            </compilation>  
+        </system.web>  
+    </configuration>  
+
 ```
 {% endtab %}
 

@@ -5,6 +5,7 @@ cvss-score: 4.2
 cvss-vector: CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
 cwe-id: CWE-310
 cwe-name: Cryptographic Issues
+correlatable: SAST
 compliance:
   HIPAA: 164.306(a), 164.312(c)(1), 164.312(e)(1)
   ISO 27001: A.5.14, A.8.9, A.8.24
@@ -14,24 +15,24 @@ compliance:
 
 ---            
 
-We identified one or more issues with your X509 server certificate, which are detailed further below.
-
-This finding usually means that the certificate was emitted with insecure attributes. Common examples include:
-
-  * Using 1024-bit RSA keys;
-  * Using the MD5 hashing algorithm for digital signatures;
+We identified one or more issues with your X509 server certificate, which are detailed further below.
+
+This finding usually means that the certificate was emitted with insecure attributes. Common examples include:
+
+  * Using 1024-bit RSA keys;
+  * Using the MD5 hashing algorithm for digital signatures;
   * Having an invalid `keyUsage` attribute. For example, using a certificate whose purpose does not allow it to be used for Digital Signature or Key Agreement.
 
 ## How to fix
 
 {% tabs certificate-with-insufficient-key-size-or-usage-or-insecure-signature-algorithm %}
 {% tab certificate-with-insufficient-key-size-or-usage-or-insecure-signature-algorithm generic %}
-Please replace your X509 certificate as soon as possible. Use a certificate from a Certification Authority trusted by modern browsers, which should guarantee it fulfills all security requirements. If you are unsure about choosing a Certificate Authority, we recommend [Let's Encrypt](https://letsencrypt.org/). Let's Encrypt provides modern X509 certificates at no cost.
-
-If you are using an internal Certificate Authority, or are using self-signed certificates, please ensure that the following requirements are met:
-
-  * Use RSA certificates with, at least, 2048-bit key size, or EC certificates with, at least, 256-bit key size;
-  * Ensure that a strong hash function is used in the certificate digital signature, such as SHA-256;
+Please replace your X509 certificate as soon as possible. Use a certificate from a Certification Authority trusted by modern browsers, which should guarantee it fulfills all security requirements. If you are unsure about choosing a Certificate Authority, we recommend [Let's Encrypt](https://letsencrypt.org/). Let's Encrypt provides modern X509 certificates at no cost.
+
+If you are using an internal Certificate Authority, or are using self-signed certificates, please ensure that the following requirements are met:
+
+  * Use RSA certificates with, at least, 2048-bit key size, or EC certificates with, at least, 256-bit key size;
+  * Ensure that a strong hash function is used in the certificate digital signature, such as SHA-256;
   * Ensure that the `keyUsage` attribute has the required flags: Digital Signature and Key Agreement.
 {% endtab %}
 

@@ -5,6 +5,7 @@ cvss-score: 3.1
 cvss-vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N
 cwe-id: CWE-16
 cwe-name: Configuration
+correlatable: SAST
 compliance:
   HIPAA: 164.306(a)
   ISO 27001: A.8.25
@@ -14,18 +15,18 @@ compliance:
 
 ---            
 
-Not having the HttpOnly flag means that the cookie can be accessed by client side scripts, such as JavaScript. This vulnerability by itself is not useful to an attacker since he has no control over client side scripts. However, if a Cross Site Scripting (XSS) vulnerability is present, he might be able to introduce a malicious script in the application, and without the HttpOnly flag, he could read the vulnerable cookie's value.
-
-The most interesting cookie for an attacker is usually the session cookie as it allows him to steal the user's session. Other cookies might be interesting also, depending on the application and the cookie's purposes, so a good rule-of-thumb is to set HttpOnly flag to all cookies.
-
+Not having the HttpOnly flag means that the cookie can be accessed by client side scripts, such as JavaScript. This vulnerability by itself is not useful to an attacker since he has no control over client side scripts. However, if a Cross Site Scripting (XSS) vulnerability is present, he might be able to introduce a malicious script in the application, and without the HttpOnly flag, he could read the vulnerable cookie's value.
+
+The most interesting cookie for an attacker is usually the session cookie as it allows him to steal the user's session. Other cookies might be interesting also, depending on the application and the cookie's purposes, so a good rule-of-thumb is to set HttpOnly flag to all cookies.
+
 Mitigating this kind of vulnerability greatly reduces the impact of other possible vulnerabilities, such as XSS, which are very common in most sites.
 
 ## How to fix
 
 {% tabs cookie-without-httponly-flag %}
 {% tab cookie-without-httponly-flag generic %}
-To fix a vulnerability of this type, you just need to set the HttpOnly flag on the vulnerable cookie, effectively preventing it from being read by client side scripts.
-
+To fix a vulnerability of this type, you just need to set the HttpOnly flag on the vulnerable cookie, effectively preventing it from being read by client side scripts.
+
 Depending on the language and technologies you are using, setting the HttpOnly flag could mean to enable it or setting it to true, either on the code of the application itself or in a configuration file of the webserver or Content Management System (CMS) you are using.
 {% endtab %}
 

@@ -5,6 +5,7 @@ cvss-score: 3.7
 cvss-vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
 cwe-id: CWE-93
 cwe-name: Improper Neutralization of CRLF Sequences ('CRLF Injection')
+correlatable: SAST
 compliance:
   HIPAA: 164.306(a)
   ISO 27001: A.5.33, A.5.34, A.8.3, A.8.12
@@ -14,19 +15,19 @@ compliance:
 
 ---            
 
-A CRLF injection vulnerability allows an attacker to inject a CR (Carriage Return: ASCII 13, \r) and a LF (Line Feed: ASCII 10, \n) in user inputs, which are then inserted in the response to terminate lines and divide the header from the body in HTTP responses, in an unexpected manner.
-
+A CRLF injection vulnerability allows an attacker to inject a CR (Carriage Return: ASCII 13, \r) and a LF (Line Feed: ASCII 10, \n) in user inputs, which are then inserted in the response to terminate lines and divide the header from the body in HTTP responses, in an unexpected manner.
+
 With a CRLF injection, an attacker takes control of the response body to perpetrate the attack. For example, the CRLF might allow the attacker to do an XSS (cross-site scripting) attack by removing the CSP (content security policy) protection and injecting malicious JavaScript into the body.
 
 ## How to fix
 
 {% tabs crlf-injection %}
 {% tab crlf-injection generic %}
-To prevent a CRLF injection vulnerability, you should:
-
- * Not insert user input in the response headers.
- * Use a library method that properly encodes header values.
-
+To prevent a CRLF injection vulnerability, you should:
+
+ * Not insert user input in the response headers.
+ * Use a library method that properly encodes header values.
+
 If your application needs to allow user input in a header, ensure the input only contains characters from a limited list, for instance, only alpha-numeric ones.
 {% endtab %}
 

@@ -5,6 +5,7 @@ cvss-score: 4.2
 cvss-vector: CVSS:3.0/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
 cwe-id: CWE-327
 cwe-name: Use of a Broken or Risky Cryptographic Algorithm
+correlatable: SAST
 compliance:
   HIPAA: 164.306(a), 164.312(c)(1), 164.312(e)(1)
   ISO 27001: A.5.14, A.8.9, A.8.24
@@ -14,87 +15,87 @@ compliance:
 
 ---            
 
-TLS protocol version 1.0 is deprecated and is now considered insecure by security researchers and standards organizations alike. For example, the PCI (Payment Card Industry) Security Standards Council requires that TLS 1.0 is disabled starting from mid-2018.
-
-This version has a design flaw in the way encryption Initialization Vectors (IVs) are handled, and security researchers devised an attack called BEAST that may allow an attacker to eavesdrop on connections using TLS 1.0.
-However, note that TLS 1.0 is not immediately insecure, especially because BEAST is primarily a client-side attack, so if browsers are up-to-date, the connections should be safe.
-
-In any case, the attacker needs to be able to eavesdrop and intercept the connection before being able to deliver the attack. This may be fairly common considering the frequency that clients establish connections over open Wi-Fi.
-
+TLS protocol version 1.0 is deprecated and is now considered insecure by security researchers and standards organizations alike. For example, the PCI (Payment Card Industry) Security Standards Council requires that TLS 1.0 is disabled starting from mid-2018.
+
+This version has a design flaw in the way encryption Initialization Vectors (IVs) are handled, and security researchers devised an attack called BEAST that may allow an attacker to eavesdrop on connections using TLS 1.0.
+However, note that TLS 1.0 is not immediately insecure, especially because BEAST is primarily a client-side attack, so if browsers are up-to-date, the connections should be safe.
+
+In any case, the attacker needs to be able to eavesdrop and intercept the connection before being able to deliver the attack. This may be fairly common considering the frequency that clients establish connections over open Wi-Fi.
+
 If you'd like to know more about secure TLS deployments, we have written an extensive article about it [here](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454).
 
 ## How to fix
 
 {% tabs deprecated-tls-protocol-version-10-supported %}
 {% tab deprecated-tls-protocol-version-10-supported generic %}
-To fix this issue, you need to disable TLS 1.0. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above.
-
-For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that.
-
-If you are using Nginx, you may use the following snippet as a guideline:
-
-```
-server {
-    listen 443 ssl;
-    ...
-    ssl_protocols TLSv1.2 TLSv1.3;
-    ...
-}
-```
-
-If using an Apache server, please refer to the following example:
-
-```
-<VirtualHost *:443>
-    ...
-    SSLProtocol        -all +TLSv1.2 +TLSv1.3
-    ...
-</VirtualHost>
-```
-
-Note that we are enabling TLS 1.2 and above, reflecting our ideal scenario.
-
+To fix this issue, you need to disable TLS 1.0. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above.
+
+For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that.
+
+If you are using Nginx, you may use the following snippet as a guideline:
+
+```
+server {
+    listen 443 ssl;
+    ...
+    ssl_protocols TLSv1.2 TLSv1.3;
+    ...
+}
+```
+
+If using an Apache server, please refer to the following example:
+
+```
+<VirtualHost *:443>
+    ...
+    SSLProtocol        -all +TLSv1.2 +TLSv1.3
+    ...
+</VirtualHost>
+```
+
+Note that we are enabling TLS 1.2 and above, reflecting our ideal scenario.
+
 If you need to cater to clients with very old TLS support, such as ancient mobile devices, and know what you are doing, you can keep TLS 1.0 enabled, despite the known weaknesses. These issues are not as serious as the SSL protocol weaknesses, but you should weigh the need to support older clients with the risk of exposing private data. Moreover, keep in mind that TLS 1.2 support is well over [95%](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454).
 {% endtab %}
 
 {% tab deprecated-tls-protocol-version-10-supported nginx %}
-To fix this issue you need to disable TLS 1.0. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above.
-
-For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that.
-
-For Nginx, you may use the following snippet as a guideline:
-
-```
-server {
-    listen 443 ssl;
-    ...
-    ssl_protocols TLSv1.2 TLSv1.3;
-    ...
-}
-```
-
-Note that we are enabling TLS 1.2 and above, reflecting our ideal scenario.
-
+To fix this issue you need to disable TLS 1.0. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above.
+
+For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that.
+
+For Nginx, you may use the following snippet as a guideline:
+
+```
+server {
+    listen 443 ssl;
+    ...
+    ssl_protocols TLSv1.2 TLSv1.3;
+    ...
+}
+```
+
+Note that we are enabling TLS 1.2 and above, reflecting our ideal scenario.
+
 If you need to cater to clients with very old TLS support, such as ancient mobile devices, and know what you are doing, you can keep TLS 1.0 enabled, despite the known weaknesses. These issues are not as serious as the SSL protocol weaknesses, but you should weight the need to support older clients with the risk of exposing private data. Moreover, keep in mind that TLS 1.2 support is well over [95%](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454).
 {% endtab %}
 
 {% tab deprecated-tls-protocol-version-10-supported apache %}
-To fix this issue you need to disable TLS 1.0. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above.
-
-For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that.
-
-If using an Apache server, please refer to the following example:
-
-```
-<VirtualHost *:443>
-    ...
-    SSLProtocol        -all +TLSv1.2 +TLSv1.3
-    ...
-</VirtualHost>
-```
-
-Note that we are enabling TLS 1.2 and TLS 1.3, reflecting our ideal scenario.
-
+To fix this issue you need to disable TLS 1.0. We also recommend that higher TLS protocol versions are enabled, ideally version 1.2 and above.
+
+For most systems, enabling or disabling TLS versions requires a change on the web server configuration file. Therefore, refer to your web server documentation on how to do that.
+
+If using an Apache server, please refer to the following example:
+
+```
+<VirtualHost *:443>
+    ...
+    SSLProtocol        -all +TLSv1.2 +TLSv1.3
+    ...
+</VirtualHost>
+```
+
+Note that we are enabling TLS 1.2 and TLS 1.3, reflecting our ideal scenario.
+
 If you need to cater to clients with very old TLS support, such as ancient mobile devices, and know what you are doing, you can keep TLS 1.0 enabled, despite the known weaknesses. These issues are not as serious as the SSL protocol weaknesses, but you should weight the need to support older clients with the risk of exposing private data. Moreover, keep in mind that TLS 1.2 support is well over [95%](https://blog.probely.com/how-to-deploy-modern-tls-in-2018-1b9a9cafc454).
 {% endtab %}