Go

Calling Close() method may return an error, and ignoring the same might result in a data loss. This is similar to many more Close methods.

Validation logic against just javascript is not enough. Instead, it should be extended for vbscript and data as URLs with these schemes also allow encoding the code with similar semantics as javascript scheme.

gRPC is designed to work with various authentication mechanisms, making it easy to use gRPC to talk to other systems. It is recommended to use the supported authentication mechanisms to shield against multiple types of attacks (e.g., MITM - Man in the Middle Attack).

XML specification allows the use of entities that can be internal or external (file system/network access, etc.) which could lead to vulnerabilities such as SSRF or confidential file disclosures. XML package (Go binding to libxml2) might be vulnerable to XXE attacks. When dealing with external entities, one must be very careful when using the package, allowing an attacker to access sensitive data on the filesystem.

Possible insecure use of logger because of tainted, untrusted, or sensitive arguments passed to the logger. Logging invalidated user input can allow an attacker to forge log entries or inject malicious content into the logs.

Go's encoding/xml is vulnerable for security-critical operations such as XML signature validation and SAML.

The components used for constructing the XPath expression might include sensitive information, possibly making it a malicious XPath expression that could lead to XPath injections. It is recommended to have the sensitive information in an XPath expression followed by pre-compiling the query and using variable references to include the same for safer construction.

A command invocation (os/exec) built from user-provided data without sufficient sanitization may run commands to exfiltrate data or compromise the system. It is recommended to either avoid using the user-provided data directly in command invocations or sanitize them before use.

Dealing with untrusted URLs may allow attacks such as request forgeries and malicious redirections unless they are sanitized. Regular expressions are often used to check the hosts or match them against a set of allowed hosts to prevent such attacks. It is recommended to escape the regular expression's meta characters correctly and make the expression restrictive (or permissive) as much as possible.

Code that forms a string containing a quoted substring must guarantee that any user-provided data embedded between the quotes does not itself have a quote. Else, the embedded data could (accidentally or intentionally) change the overall structure by terminating the quoted substring early, with potentially severe consequences like command injection or SQL injection attacks. It is recommended to use the squirrel's placeholder syntax or sanitize the embedded data appropriately to ensure quotes are escaped or use an API that does not manually construct quoted substrings.

DES is cryptographically broken and should not be used for secure applications. It is recommended to use better replacement algorithms instead.

MD5 is cryptographically broken and should not be used for secure applications. It is recommended to use better replacement algorithms instead.

RC4 is cryptographically broken and should not be used for secure applications. It is recommended to use an alternate algorithm instead.

SHA1 is cryptographically broken and should not be used for secure applications. It is recommended to use an alternate algorithm instead.

(*crypto/x509.Certificate).Verify accepts a CurrentTime parameter to specify the system time used to verify the certificate. Providing something other than the current system time may allow expired certificates to be marked as valid.

A secure cookie instructs the browser not to send the cookie in insecure contexts such as while using HTTP. This prevents session stealing via a MITM attack.

Same-Site: None cookies are available on cross-origin requests making the application vulnerable to CSRF (cross-site request forgery) attacks. It is recommended to use Same-Site: Lax or Same-Site: Strict depending on the application requirements.

Same-Site: None cookies are available on cross-origin requests making the application vulnerable to CSRF (cross-site request forgery) attacks. It is recommended to use Same-Site: Lax or Same-Site: Strict depending on the application requirements.

Be careful when using doublestar.Glob as it internally uses os.Stat, and that does follow symbolic links (symlinks). In case there's a symlink loop in the filesystem, the Glob function might result in out-of-memory. Please audit your code for the same. An attacker might use this vulnerability to their advantage and introduce uncontrolled resource consumption where file paths gets piled up and leads to process being killed by OOM killer.