{"$schema":"https://json.schemastore.org/sarif-2.1.0.json","version":"2.1.0","runs":[{"tool":{"driver":{"name":"Bearer","rules":[{"id":"go_gosec_filesystem_decompression_bomb","name":"go_gosec_filesystem_decompression_bomb","shortDescription":{"text":"Missing configuration against decompression bomb"},"fullDescription":{"text":"Missing configuration against decompression bomb"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nDecompression bombs pose a risk by exploiting applications that process compressed files. These attacks involve a compressed file that is small in size but expands to a significantly larger size when decompressed. This can overwhelm system resources such as CPU, memory, or disk space, causing a Denial of Service (DoS).\n\n## Remediations\n\n- **Do** limit the decompression size. Use `io.LimitReader`, for example, to restrict the amount of data that a reader will decompress. This prevents the decompression of large files that could fill up memory or disk space.\n  ```go\n  const maxDecompressSize = 10 * 1024 * 1024 // 10 MB\n  limitedReader := io.LimitReader(r, maxDecompressSize)\n  ```\n- **Do** monitor resource usage to detect unexpected increases in CPU, memory, or disk usage, which may indicate an attack.\n- **Do** validate the size and type of input files before decompression. Reject files that do not meet predefined criteria to avoid processing potentially harmful data.\n- **Do** ensure your application fails safely. It should handle decompression errors without crashing or becoming unresponsive.\n- **Do** regularly update your compression libraries to incorporate the latest security patches and protect against known vulnerabilities.\n- **Do** educate users about the risks associated with decompression bombs, especially if they have the ability to upload compressed files.","markdown":"## Description\n\nDecompression bombs pose a risk by exploiting applications that process compressed files. These attacks involve a compressed file that is small in size but expands to a significantly larger size when decompressed. This can overwhelm system resources such as CPU, memory, or disk space, causing a Denial of Service (DoS).\n\n## Remediations\n\n- **Do** limit the decompression size. Use `io.LimitReader`, for example, to restrict the amount of data that a reader will decompress. This prevents the decompression of large files that could fill up memory or disk space.\n  ```go\n  const maxDecompressSize = 10 * 1024 * 1024 // 10 MB\n  limitedReader := io.LimitReader(r, maxDecompressSize)\n  ```\n- **Do** monitor resource usage to detect unexpected increases in CPU, memory, or disk usage, which may indicate an attack.\n- **Do** validate the size and type of input files before decompression. Reject files that do not meet predefined criteria to avoid processing potentially harmful data.\n- **Do** ensure your application fails safely. It should handle decompression errors without crashing or becoming unresponsive.\n- **Do** regularly update your compression libraries to incorporate the latest security patches and protect against known vulnerabilities.\n- **Do** educate users about the risks associated with decompression bombs, especially if they have the ability to upload compressed files."}},{"id":"go_lang_missing_tls_minversion","name":"go_lang_missing_tls_minversion","shortDescription":{"text":"Missing TLS MinVersion"},"fullDescription":{"text":"Missing TLS MinVersion"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nOlder versions of TLS (Transport Layer Security) have been deprecated because of known security issues. To enhance security, it is crucial to specify the highest possible minimum version of TLS that your server will accept.\n\n## Remediations\n\n- **Do** set `MinVersion` in the `tls.Config` struct to `tls.VersionTLS13`. This ensures your server only accepts connections using the most secure, up-to-date version of TLS.\n  ```go\n  {\n    MinVersion: tls.VersionTLS13\n  }\n  ```\n- **Do** configure `MinVersion` to the highest possible supported version of TLS for legacy applications that cannot use TLS 1.3. This step is essential for maintaining security while ensuring compatibility.\n\n## References\n\n- [OWASP TLS Cipher String Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/TLS_Cipher_String_Cheat_Sheet.html)","markdown":"## Description\n\nOlder versions of TLS (Transport Layer Security) have been deprecated because of known security issues. To enhance security, it is crucial to specify the highest possible minimum version of TLS that your server will accept.\n\n## Remediations\n\n- **Do** set `MinVersion` in the `tls.Config` struct to `tls.VersionTLS13`. This ensures your server only accepts connections using the most secure, up-to-date version of TLS.\n  ```go\n  {\n    MinVersion: tls.VersionTLS13\n  }\n  ```\n- **Do** configure `MinVersion` to the highest possible supported version of TLS for legacy applications that cannot use TLS 1.3. This step is essential for maintaining security while ensuring compatibility.\n\n## References\n\n- [OWASP TLS Cipher String Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/TLS_Cipher_String_Cheat_Sheet.html)"}},{"id":"go_third_parties_algolia","name":"go_third_parties_algolia","shortDescription":{"text":"Leakage of sensitive data to Algolia"},"fullDescription":{"text":"Leakage of sensitive data to Algolia"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to third-party data tools like Algolia is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party services like Algolia.\n\n## References\n- [Algolia docs](https://www.algolia.com/doc/)\n","markdown":"## Description\n\nLeaking sensitive data to third-party data tools like Algolia is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party services like Algolia.\n\n## References\n- [Algolia docs](https://www.algolia.com/doc/)\n"}},{"id":"go_lang_open_redirect","name":"go_lang_open_redirect","shortDescription":{"text":"Unsanitized user input in redirect"},"fullDescription":{"text":"Unsanitized user input in redirect"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nUsing unsanitized user input to perform redirects can expose your application to phishing attacks. This vulnerability arises when user input directly influences the destination of a redirect without proper validation, making it easier for attackers to deceive users by directing them to malicious sites.\n\n## Remediations\n\n- **Do not** use unsanitized user input to construct URLs for redirects. This can lead to security vulnerabilities where attackers might redirect users to malicious websites.\n- **Do** validate all user input used in redirects. Employ a whitelist approach or a mapping of allowed destinations to ensure only safe and intended URLs are used for redirection.\n  ```go\n  var URLMapping = map[string]string{\n    \"google\": \"https://www.google.com\",\n    \"openai\": \"https://www.openai.com\",\n    \"github\": \"https://www.github.com\",\n    \"root\":   \"https://www.example.com\",\n  }\n\n  func safeRedirectHandler(w http.ResponseWriter, r *http.Request) {\n    // Get the redirectTo parameter from the query string\n    redirectTo := r.URL.Query().Get(\"redirectTo\")\n\n    // Get the safe URL from the map, default to the URL for \"root\" if not found\n    redirectURL, ok := URLMapping[redirectTo]\n    if !ok {\n      redirectURL = URLMapping[\"root\"] // Default to a predefined safe URL\n    }\n\n    ...\n  }\n  ```\n\n## References\n\n- [OWASP Unvalidated Redirects and Forwards Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html)","markdown":"## Description\n\nUsing unsanitized user input to perform redirects can expose your application to phishing attacks. This vulnerability arises when user input directly influences the destination of a redirect without proper validation, making it easier for attackers to deceive users by directing them to malicious sites.\n\n## Remediations\n\n- **Do not** use unsanitized user input to construct URLs for redirects. This can lead to security vulnerabilities where attackers might redirect users to malicious websites.\n- **Do** validate all user input used in redirects. Employ a whitelist approach or a mapping of allowed destinations to ensure only safe and intended URLs are used for redirection.\n  ```go\n  var URLMapping = map[string]string{\n    \"google\": \"https://www.google.com\",\n    \"openai\": \"https://www.openai.com\",\n    \"github\": \"https://www.github.com\",\n    \"root\":   \"https://www.example.com\",\n  }\n\n  func safeRedirectHandler(w http.ResponseWriter, r *http.Request) {\n    // Get the redirectTo parameter from the query string\n    redirectTo := r.URL.Query().Get(\"redirectTo\")\n\n    // Get the safe URL from the map, default to the URL for \"root\" if not found\n    redirectURL, ok := URLMapping[redirectTo]\n    if !ok {\n      redirectURL = URLMapping[\"root\"] // Default to a predefined safe URL\n    }\n\n    ...\n  }\n  ```\n\n## References\n\n- [OWASP Unvalidated Redirects and Forwards Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html)"}},{"id":"go_lang_weak_password_encryption_md5","name":"go_lang_weak_password_encryption_md5","shortDescription":{"text":"Usage of weak hashing library on a password (MD5)"},"fullDescription":{"text":"Usage of weak hashing library on a password (MD5)"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nUsing a weak hashing library like MD5 for password storage compromises security. MD5 is outdated and vulnerable, making it easier for attackers to crack passwords and gain unauthorized access.\n\n## Remediations\n\n- **Do not** use MD5 for hashing passwords. This algorithm is no longer considered secure due to its vulnerability to collision and preimage attacks.\n  ```go\n  md5.Sum([]byte('password')) // unsafe\n  ```\n- **Do** use stronger hashing algorithms such as SHA-256 for password hashing. These provide enhanced security and resistance against attacks.\n  ```go\n  sha256.Sum256([]byte('string'))\n  ```","markdown":"## Description\n\nUsing a weak hashing library like MD5 for password storage compromises security. MD5 is outdated and vulnerable, making it easier for attackers to crack passwords and gain unauthorized access.\n\n## Remediations\n\n- **Do not** use MD5 for hashing passwords. This algorithm is no longer considered secure due to its vulnerability to collision and preimage attacks.\n  ```go\n  md5.Sum([]byte('password')) // unsafe\n  ```\n- **Do** use stronger hashing algorithms such as SHA-256 for password hashing. These provide enhanced security and resistance against attacks.\n  ```go\n  sha256.Sum256([]byte('string'))\n  ```"}},{"id":"go_third_parties_rollbar","name":"go_third_parties_rollbar","shortDescription":{"text":"Leakage of sensitive data to RollBar"},"fullDescription":{"text":"Leakage of sensitive data to RollBar"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to third-party loggers like Rollbar is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party loggers like Rollbar.\n\n## References\n- [Rollbar docs](https://docs.rollbar.com/docs/go)\n","markdown":"## Description\n\nLeaking sensitive data to third-party loggers like Rollbar is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party loggers like Rollbar.\n\n## References\n- [Rollbar docs](https://docs.rollbar.com/docs/go)\n"}},{"id":"go_third_parties_new_relic","name":"go_third_parties_new_relic","shortDescription":{"text":"Leakage of sensitive data to New Relic"},"fullDescription":{"text":"Leakage of sensitive data to New Relic"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to third-party loggers like New Relic is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party loggers like New Relic\n\n## References\n- [New Relic Docs](https://docs.newrelic.com/)\n- [Log obfuscation](https://docs.newrelic.com/docs/logs/ui-data/obfuscation-ui/)\n","markdown":"## Description\n\nLeaking sensitive data to third-party loggers like New Relic is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party loggers like New Relic\n\n## References\n- [New Relic Docs](https://docs.newrelic.com/)\n- [Log obfuscation](https://docs.newrelic.com/docs/logs/ui-data/obfuscation-ui/)\n"}},{"id":"go_lang_weak_hash_md5","name":"go_lang_weak_hash_md5","shortDescription":{"text":"Usage of weak hashing library (MD5)"},"fullDescription":{"text":"Usage of weak hashing library (MD5)"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nUsing a weak hashing library like MD5 increases the risk of data breaches. MD5 is vulnerable to collision attacks, where two different inputs produce the same output, compromising data integrity and security.\n\n## Remediations\n\n- **Do not** use MD5 for hashing. It is considered a weak hash algorithm and can compromise data security.\n  ```go\n  md5.Sum([]byte(\"password\")) // unsafe\n  ```\n- **Do** opt for stronger hashing algorithms such as SHA-256 to enhance security.\n  ```go\n  sha256.Sum256([]byte(\"string\"))\n  ```","markdown":"## Description\n\nUsing a weak hashing library like MD5 increases the risk of data breaches. MD5 is vulnerable to collision attacks, where two different inputs produce the same output, compromising data integrity and security.\n\n## Remediations\n\n- **Do not** use MD5 for hashing. It is considered a weak hash algorithm and can compromise data security.\n  ```go\n  md5.Sum([]byte(\"password\")) // unsafe\n  ```\n- **Do** opt for stronger hashing algorithms such as SHA-256 to enhance security.\n  ```go\n  sha256.Sum256([]byte(\"string\"))\n  ```"}},{"id":"go_third_parties_airbrake","name":"go_third_parties_airbrake","shortDescription":{"text":"Leakage of sensitive data to Airbrake"},"fullDescription":{"text":"Leakage of sensitive data to Airbrake"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to third-party loggers like Airbrake is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when logging errors or events to Airbrake\n\n## References\n- [Airbrake Docs](https://docs.airbrake.io/)\n","markdown":"## Description\n\nLeaking sensitive data to third-party loggers like Airbrake is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when logging errors or events to Airbrake\n\n## References\n- [Airbrake Docs](https://docs.airbrake.io/)\n"}},{"id":"go_gosec_filesystem_filereadtaint","name":"go_gosec_filesystem_filereadtaint","shortDescription":{"text":"Unsanitized user input in file path"},"fullDescription":{"text":"Unsanitized user input in file path"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nUsing user input to dynamically construct file paths without proper sanitization introduces a high security risk. This practice can allow attackers to manipulate file paths to access or alter sensitive files, potentially leading to data breaches or system compromise. It is essential to sanitize user input before using it in file system operations to prevent path traversal attacks.\n\n## Remediations\n\n- **Do not** use unsanitized user input directly in file path construction. This can lead to path traversal vulnerabilities.\n- **Do** hash or replace user input with a system-generated unique identifier when constructing file paths. This approach minimizes the risk of path manipulation.\n- **Do** use `filepath.Base` to extract the filename from a path, discarding any directory information. This helps prevent directory traversal attacks.\n  ```go\n  safeFilename := filepath.Base(userInput)\n  ```\n- **Do** validate paths before accessing files to ensure they are within the intended directory. This validation acts as a safeguard against unauthorized file access.\n\n## References\n\n- [OWASP Guide to Preventing Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal)","markdown":"## Description\n\nUsing user input to dynamically construct file paths without proper sanitization introduces a high security risk. This practice can allow attackers to manipulate file paths to access or alter sensitive files, potentially leading to data breaches or system compromise. It is essential to sanitize user input before using it in file system operations to prevent path traversal attacks.\n\n## Remediations\n\n- **Do not** use unsanitized user input directly in file path construction. This can lead to path traversal vulnerabilities.\n- **Do** hash or replace user input with a system-generated unique identifier when constructing file paths. This approach minimizes the risk of path manipulation.\n- **Do** use `filepath.Base` to extract the filename from a path, discarding any directory information. This helps prevent directory traversal attacks.\n  ```go\n  safeFilename := filepath.Base(userInput)\n  ```\n- **Do** validate paths before accessing files to ensure they are within the intended directory. This validation acts as a safeguard against unauthorized file access.\n\n## References\n\n- [OWASP Guide to Preventing Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal)"}},{"id":"go_gosec_crypto_bad_tls_settings","name":"go_gosec_crypto_bad_tls_settings","shortDescription":{"text":"Usage of insecure cipher"},"fullDescription":{"text":"Usage of insecure cipher"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nUsing an insecure cipher suite in your application introduces a significant security risk. These weak cipher suites are susceptible to various attacks, compromising the security of your communications.\n\n## Remediations\n\n- **Do** use modern, secure cipher suites that offer Perfect Forward Secrecy (PFS), such as ECDHE-RSA-AES256-GCM-SHA384 or ECDHE-RSA-CHACHA20-POLY1305. PFS ensures that even if future private keys are compromised, past communications remain secure.\n- **Do** adopt TLS 1.3 whenever possible, as it includes enhancements that offer better security against various attacks. The Go standard library, for instance, automatically prefers the most secure protocol and cipher suite available.\n  ```go\n  cfg := \u0026tls.Config{\n      MinVersion: tls.VersionTLS13,\n  }\n  ```\n- **Do not** use obsolete or insecure cipher suites. Avoid any cipher suites that lack support for modern security standards or have known vulnerabilities.\n\n## References\n\n- [Mozilla's SSL Configuration Generator](https://ssl-config.mozilla.org/)\n- [OWASP TLS Cipher String Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/TLS_Cipher_String_Cheat_Sheet.html)\n- [RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3](https://tools.ietf.org/html/rfc8446)","markdown":"## Description\n\nUsing an insecure cipher suite in your application introduces a significant security risk. These weak cipher suites are susceptible to various attacks, compromising the security of your communications.\n\n## Remediations\n\n- **Do** use modern, secure cipher suites that offer Perfect Forward Secrecy (PFS), such as ECDHE-RSA-AES256-GCM-SHA384 or ECDHE-RSA-CHACHA20-POLY1305. PFS ensures that even if future private keys are compromised, past communications remain secure.\n- **Do** adopt TLS 1.3 whenever possible, as it includes enhancements that offer better security against various attacks. The Go standard library, for instance, automatically prefers the most secure protocol and cipher suite available.\n  ```go\n  cfg := \u0026tls.Config{\n      MinVersion: tls.VersionTLS13,\n  }\n  ```\n- **Do not** use obsolete or insecure cipher suites. Avoid any cipher suites that lack support for modern security standards or have known vulnerabilities.\n\n## References\n\n- [Mozilla's SSL Configuration Generator](https://ssl-config.mozilla.org/)\n- [OWASP TLS Cipher String Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/TLS_Cipher_String_Cheat_Sheet.html)\n- [RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3](https://tools.ietf.org/html/rfc8446)"}},{"id":"go_gosec_sql_concat_sqli","name":"go_gosec_sql_concat_sqli","shortDescription":{"text":"Unsanitized user input in SQL query"},"fullDescription":{"text":"Unsanitized user input in SQL query"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nSQL Injection is a critical vulnerability that arises when SQL queries are dynamically constructed using unsanitized user input. This flaw allows attackers to alter the intended logic of SQL statements, potentially leading to unauthorized access to sensitive data or the execution of arbitrary code on the system.\n\n## Remediations\n\n- **Do** use parameterized queries to prevent SQL injection. This method ensures that user input is treated as data, not as part of the SQL command, effectively neutralizing the threat.\n  ```go\n  db.Query(\"SELECT * FROM users WHERE userName = ?\", userName)\n  ```\n- **Do not** use direct user input in dynamic queries. If you must create dynamic queries, use a predefined map or dictionary of valid values (a safelist). This approach allows you to safely include user input by translating it into safe, predefined commands or values.\n\n## References\n\n- [OWASP SQL Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html)","markdown":"## Description\n\nSQL Injection is a critical vulnerability that arises when SQL queries are dynamically constructed using unsanitized user input. This flaw allows attackers to alter the intended logic of SQL statements, potentially leading to unauthorized access to sensitive data or the execution of arbitrary code on the system.\n\n## Remediations\n\n- **Do** use parameterized queries to prevent SQL injection. This method ensures that user input is treated as data, not as part of the SQL command, effectively neutralizing the threat.\n  ```go\n  db.Query(\"SELECT * FROM users WHERE userName = ?\", userName)\n  ```\n- **Do not** use direct user input in dynamic queries. If you must create dynamic queries, use a predefined map or dictionary of valid values (a safelist). This approach allows you to safely include user input by translating it into safe, predefined commands or values.\n\n## References\n\n- [OWASP SQL Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html)"}},{"id":"go_gosec_http_http_slowloris","name":"go_gosec_http_http_slowloris","shortDescription":{"text":"Missing protection against 'Slowloris' attack"},"fullDescription":{"text":"Missing protection against 'Slowloris' attack"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nYour server configuration is missing the `ReadHeaderTimeout` setting, making it vulnerable to a type of Distributed Denial of Service (DDoS) attack known as a Slowloris attack. In such an attack, a hacker initiates many connections to your server, sending incomplete requests. Your server then keeps each connection open, waiting for the headers to be completed. This can lead to resource exhaustion, where your server cannot handle additional (legitimate) requests.\n\n## Remediations\n\n- **Do not** use default serve functions like `http.ListenAndServe` and `http.Serve` in production environments. You cannot set timeouts for these functions, making the server vulnerable to attacks.\n  ```go\n  http.ListenAndServe(\":8080\", nil) // unsafe\n  ```\n- **Do** create a custom `http.Server` object with configured timeouts to safeguard against resource exhaustion. For Slowloris attacks in particular, set `ReadHeaderTimeout` to an appropriate value to ensure that connections do not remain open indefinitely.\n  ```go\n  myServer := \u0026http.Server{\n      Addr:             \"localhost:8000\",\n      ReadHeaderTimeout: 15 * time.Second,\n      ReadTimeout:      15 * time.Second,\n      WriteTimeout:     10 * time.Second,\n      IdleTimeout:      30 * time.Second,\n  }\n  ```\n\n## References\n\n- [Configuring Timeouts in http.Server](https://pkg.go.dev/net/http#Server)\n- [How to Set Request-Based Timeouts](https://pkg.go.dev/net/http#TimeoutHandler)\n- [Understanding Slowloris Attacks](https://en.wikipedia.org/wiki/Slowloris_(computer_security))","markdown":"## Description\n\nYour server configuration is missing the `ReadHeaderTimeout` setting, making it vulnerable to a type of Distributed Denial of Service (DDoS) attack known as a Slowloris attack. In such an attack, a hacker initiates many connections to your server, sending incomplete requests. Your server then keeps each connection open, waiting for the headers to be completed. This can lead to resource exhaustion, where your server cannot handle additional (legitimate) requests.\n\n## Remediations\n\n- **Do not** use default serve functions like `http.ListenAndServe` and `http.Serve` in production environments. You cannot set timeouts for these functions, making the server vulnerable to attacks.\n  ```go\n  http.ListenAndServe(\":8080\", nil) // unsafe\n  ```\n- **Do** create a custom `http.Server` object with configured timeouts to safeguard against resource exhaustion. For Slowloris attacks in particular, set `ReadHeaderTimeout` to an appropriate value to ensure that connections do not remain open indefinitely.\n  ```go\n  myServer := \u0026http.Server{\n      Addr:             \"localhost:8000\",\n      ReadHeaderTimeout: 15 * time.Second,\n      ReadTimeout:      15 * time.Second,\n      WriteTimeout:     10 * time.Second,\n      IdleTimeout:      30 * time.Second,\n  }\n  ```\n\n## References\n\n- [Configuring Timeouts in http.Server](https://pkg.go.dev/net/http#Server)\n- [How to Set Request-Based Timeouts](https://pkg.go.dev/net/http#TimeoutHandler)\n- [Understanding Slowloris Attacks](https://en.wikipedia.org/wiki/Slowloris_(computer_security))"}},{"id":"go_third_parties_datadog","name":"go_third_parties_datadog","shortDescription":{"text":"Leakage of sensitive data to Datadog"},"fullDescription":{"text":"Leakage of sensitive data to Datadog"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to third-party loggers like Datadog is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party loggers like Datadog.\n\n## References\n- [Datadog docs](https://docs.datadoghq.com)\n- [Scrubbing data](https://docs.datadoghq.com/tracing/configure_data_security/?tab=go#scrub-sensitive-data-from-your-spans)\n","markdown":"## Description\n\nLeaking sensitive data to third-party loggers like Datadog is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party loggers like Datadog.\n\n## References\n- [Datadog docs](https://docs.datadoghq.com)\n- [Scrubbing data](https://docs.datadoghq.com/tracing/configure_data_security/?tab=go#scrub-sensitive-data-from-your-spans)\n"}},{"id":"go_gosec_injection_subproc_injection","name":"go_gosec_injection_subproc_injection","shortDescription":{"text":"Unsanitized dynamic input in OS command"},"fullDescription":{"text":"Unsanitized dynamic input in OS command"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nUsing unsanitized dynamic or external input in an OS command is a critical security flaw that can enable attackers to execute unauthorized commands on the host operating system, potentially leading to a complete system takeover.\n\n## Remediations\n\n- **Do not** construct OS commands or command-line arguments using externally-supplied information. This practice can introduce command injection vulnerabilities.\n  ```go\n  cmd := exec.Command(\"bash\", \"-c\", \"echo \" + externalInput) // unsafe\n  ```\n- **Do** validate all external input against a strict set of rules to ensure it does not include harmful characters or patterns.\n  ```go\n  if !regexp.MustCompile(`^[a-zA-Z0-9]+$`).MatchString(externalInput) {\n    log.Fatal(\"Invalid input\")\n  }\n  ```\n- **Do** use hardcoded arguments when invoking OS commands to prevent external input from altering the command's execution.\n  ```go\n  cmd := exec.Command(\"ls\", \"-l\", \"/var/log\")\n  ```\n- **Do** prefer native libraries or programming language features over invoking shell commands for enhanced security and efficiency.\n\n## References\n\n- [OWASP OS Command Injection Defense Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html)","markdown":"## Description\n\nUsing unsanitized dynamic or external input in an OS command is a critical security flaw that can enable attackers to execute unauthorized commands on the host operating system, potentially leading to a complete system takeover.\n\n## Remediations\n\n- **Do not** construct OS commands or command-line arguments using externally-supplied information. This practice can introduce command injection vulnerabilities.\n  ```go\n  cmd := exec.Command(\"bash\", \"-c\", \"echo \" + externalInput) // unsafe\n  ```\n- **Do** validate all external input against a strict set of rules to ensure it does not include harmful characters or patterns.\n  ```go\n  if !regexp.MustCompile(`^[a-zA-Z0-9]+$`).MatchString(externalInput) {\n    log.Fatal(\"Invalid input\")\n  }\n  ```\n- **Do** use hardcoded arguments when invoking OS commands to prevent external input from altering the command's execution.\n  ```go\n  cmd := exec.Command(\"ls\", \"-l\", \"/var/log\")\n  ```\n- **Do** prefer native libraries or programming language features over invoking shell commands for enhanced security and efficiency.\n\n## References\n\n- [OWASP OS Command Injection Defense Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html)"}},{"id":"go_lang_cross_site_scripting","name":"go_lang_cross_site_scripting","shortDescription":{"text":"Unsanitized user input in HTTP response (XSS)"},"fullDescription":{"text":"Unsanitized user input in HTTP response (XSS)"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nIncluding unsanitized user input in HTTP responses exposes your application to cross-site scripting (XSS) attacks. This vulnerability allows attackers to inject malicious scripts into web pages viewed by other users.\n\n## Remediations\n\n- **Do not** include user input directly in a response. This practice can lead to XSS vulnerabilities.\n```go\n  func bad(w http.ResponseWriter, r *http.Request) {\n    userInput := r.URL.Query().Get(\"input\")\n    fmt.Fprintf(w, \"\u003chtml\u003e\u003cbody\u003e%s\u003c/body\u003e\u003c/html\u003e\", userInput)\n  }\n```\n\n## References\n\n- [OWASP Cross-Site Scripting (XSS) Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)\n","markdown":"## Description\n\nIncluding unsanitized user input in HTTP responses exposes your application to cross-site scripting (XSS) attacks. This vulnerability allows attackers to inject malicious scripts into web pages viewed by other users.\n\n## Remediations\n\n- **Do not** include user input directly in a response. This practice can lead to XSS vulnerabilities.\n```go\n  func bad(w http.ResponseWriter, r *http.Request) {\n    userInput := r.URL.Query().Get(\"input\")\n    fmt.Fprintf(w, \"\u003chtml\u003e\u003cbody\u003e%s\u003c/body\u003e\u003c/html\u003e\", userInput)\n  }\n```\n\n## References\n\n- [OWASP Cross-Site Scripting (XSS) Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)\n"}},{"id":"go_lang_xml_external_entity_vulnerability","name":"go_lang_xml_external_entity_vulnerability","shortDescription":{"text":"Unsanitized user input in XML External Entity"},"fullDescription":{"text":"Unsanitized user input in XML External Entity"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\nAvoid parsing untrusted data as XML. Such data could include URIs that resolve to resources that are outside of the current context, leading to XML External Entity (XXE) injection.\n\n## Remediations\n\n- **Do** use Go’s standard `encoding/xml` package, which **does not process external entities** by default.\n\n- **Do** always validate and sanitize user-provided XML input.\n\n- **Do not** use third-party XML parsers or custom configurations that enable entity expansion or DTD parsing.\n\n## Resources\n- [OWASP XML External Entity (XXE) prevention cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html)\n- [Golang and XXE - OWASP Presentation](https://owasp.org/www-chapter-vancouver/assets/presentations/2020-08_Golang_XXE.pdf)\n","markdown":"## Description\nAvoid parsing untrusted data as XML. Such data could include URIs that resolve to resources that are outside of the current context, leading to XML External Entity (XXE) injection.\n\n## Remediations\n\n- **Do** use Go’s standard `encoding/xml` package, which **does not process external entities** by default.\n\n- **Do** always validate and sanitize user-provided XML input.\n\n- **Do not** use third-party XML parsers or custom configurations that enable entity expansion or DTD parsing.\n\n## Resources\n- [OWASP XML External Entity (XXE) prevention cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html)\n- [Golang and XXE - OWASP Presentation](https://owasp.org/www-chapter-vancouver/assets/presentations/2020-08_Golang_XXE.pdf)\n"}},{"id":"go_third_parties_google_dataflow","name":"go_third_parties_google_dataflow","shortDescription":{"text":"Leakage of sensitive data to Google Dataflow"},"fullDescription":{"text":"Leakage of sensitive data to Google Dataflow"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to a third-party service is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party services like Google Dataflow.\n\n## References\n- [Google Dataflow Docs](https://cloud.google.com/dataflow/docs/overview)\n","markdown":"## Description\n\nLeaking sensitive data to a third-party service is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party services like Google Dataflow.\n\n## References\n- [Google Dataflow Docs](https://cloud.google.com/dataflow/docs/overview)\n"}},{"id":"go_lang_cookie_missing_http_only","name":"go_lang_cookie_missing_http_only","shortDescription":{"text":"Missing HTTP Only option in cookie configuration"},"fullDescription":{"text":"Missing HTTP Only option in cookie configuration"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nMissing the HTTP Only option in cookie configuration exposes cookies to client-side script access. This vulnerability occurs when cookies are set without the `HttpOnly` attribute, allowing them to be accessible via JavaScript. This can lead to sensitive information being compromised, especially if the site is susceptible to Cross-Site Scripting (XSS) attacks.\n\n## Remediations\n\n- **Do** set the `HttpOnly` attribute for cookies to `true`. This action prevents client-side scripts from accessing the cookie, significantly reducing the risk of XSS attacks.\n  ```go\n  http.SetCookie(w, \u0026http.Cookie{\n      Name:     \"session_token\",\n      Value:    sessionToken,\n      HttpOnly: true,\n      ...\n  })\n  ```\n- **Do** also consider setting `Secure`, `SameSite`, and `Domain` attributes for cookies. These additional configurations help in further securing cookies against various web vulnerabilities, tailoring the protection to your application's specific needs.\n\n## References\n\n- [OWASP Secure Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)\n- [MDN Web Docs: HttpOnly Cookie Attribute](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies)","markdown":"## Description\n\nMissing the HTTP Only option in cookie configuration exposes cookies to client-side script access. This vulnerability occurs when cookies are set without the `HttpOnly` attribute, allowing them to be accessible via JavaScript. This can lead to sensitive information being compromised, especially if the site is susceptible to Cross-Site Scripting (XSS) attacks.\n\n## Remediations\n\n- **Do** set the `HttpOnly` attribute for cookies to `true`. This action prevents client-side scripts from accessing the cookie, significantly reducing the risk of XSS attacks.\n  ```go\n  http.SetCookie(w, \u0026http.Cookie{\n      Name:     \"session_token\",\n      Value:    sessionToken,\n      HttpOnly: true,\n      ...\n  })\n  ```\n- **Do** also consider setting `Secure`, `SameSite`, and `Domain` attributes for cookies. These additional configurations help in further securing cookies against various web vulnerabilities, tailoring the protection to your application's specific needs.\n\n## References\n\n- [OWASP Secure Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)\n- [MDN Web Docs: HttpOnly Cookie Attribute](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies)"}},{"id":"go_third_parties_bugsnag","name":"go_third_parties_bugsnag","shortDescription":{"text":"Leakage of sensitive data to Bugsnag"},"fullDescription":{"text":"Leakage of sensitive data to Bugsnag"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to third-party loggers like Bugsnag is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party loggers like Bugsnag.\n\n## References\n- [Bugsnag Docs](https://docs.bugsnag.com/platforms/go/)\n","markdown":"## Description\n\nLeaking sensitive data to third-party loggers like Bugsnag is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party loggers like Bugsnag.\n\n## References\n- [Bugsnag Docs](https://docs.bugsnag.com/platforms/go/)\n"}},{"id":"go_lang_log_output_neutralization","name":"go_lang_log_output_neutralization","shortDescription":{"text":"Missing output neutralization for logs"},"fullDescription":{"text":"Missing output neutralization for logs"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLogging unsanitized external input directly can introduce log injection vulnerabilities. This occurs when external data is logged without being cleaned, potentially allowing attackers to insert malicious content into your logs.\n\n## Remediations\n\n- **Do not** log unsanitized external input directly. This practice can make your application vulnerable to log injection attacks.\n- **Do** use printf methods with `%q` format for logging external input. This method ensures that the input is safely encoded, preventing log injection.\n  ```go\n  dangerousInput := os.Args[0]\n  logger.Printf(\"Args: %q\", dangerousInput)\n  ```\n- **Do** manually escape external strings before logging them. This approach allows you to sanitize input by escaping potentially dangerous characters.\n  ```go\n  dangerousInput := os.Args[0]\n  sanitizedInput := strconv.Quote(dangerousInput)\n  logger.Print(sanitizedInput)\n  ```","markdown":"## Description\n\nLogging unsanitized external input directly can introduce log injection vulnerabilities. This occurs when external data is logged without being cleaned, potentially allowing attackers to insert malicious content into your logs.\n\n## Remediations\n\n- **Do not** log unsanitized external input directly. This practice can make your application vulnerable to log injection attacks.\n- **Do** use printf methods with `%q` format for logging external input. This method ensures that the input is safely encoded, preventing log injection.\n  ```go\n  dangerousInput := os.Args[0]\n  logger.Printf(\"Args: %q\", dangerousInput)\n  ```\n- **Do** manually escape external strings before logging them. This approach allows you to sanitize input by escaping potentially dangerous characters.\n  ```go\n  dangerousInput := os.Args[0]\n  sanitizedInput := strconv.Quote(dangerousInput)\n  logger.Print(sanitizedInput)\n  ```"}},{"id":"go_lang_deserialization_of_user_input","name":"go_lang_deserialization_of_user_input","shortDescription":{"text":"Unsanitized user input in deserialization method"},"fullDescription":{"text":"Unsanitized user input in deserialization method"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nDeserializing data from untrusted sources, like user inputs or request parameters, without proper verification is a security risk. Attackers can embed malicious code or payloads within serialized data. When your application deserializes this data without checks, it becomes vulnerable to attacks.\n\n## Remediations\n\n- **Do not** deserialize data from untrusted sources directly. This can lead to security vulnerabilities.\n- **Do** validate and sanitize all data before deserializing it. Ensure that the data is coming from a trusted source and is in the expected format.\n\n## References\n\n- [Gob Security Documentation](https://pkg.go.dev/encoding/gob#hdr-Security)\n- [OWASP Deserialization cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html)","markdown":"## Description\n\nDeserializing data from untrusted sources, like user inputs or request parameters, without proper verification is a security risk. Attackers can embed malicious code or payloads within serialized data. When your application deserializes this data without checks, it becomes vulnerable to attacks.\n\n## Remediations\n\n- **Do not** deserialize data from untrusted sources directly. This can lead to security vulnerabilities.\n- **Do** validate and sanitize all data before deserializing it. Ensure that the data is coming from a trusted source and is in the expected format.\n\n## References\n\n- [Gob Security Documentation](https://pkg.go.dev/encoding/gob#hdr-Security)\n- [OWASP Deserialization cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html)"}},{"id":"go_gosec_network_bind_to_all_interfaces","name":"go_gosec_network_bind_to_all_interfaces","shortDescription":{"text":"Permissive server network interface configuration"},"fullDescription":{"text":"Permissive server network interface configuration"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nBinding a service to \"0.0.0.0\" makes it accessible on all network interfaces. This configuration can lead to unintended exposure over insecure or unintended network interfaces, creating potential security risks.\n\n## Remediations\n\n- **Do not** bind services to \"0.0.0.0\" without considering the security implications. This default setting can expose your service on all network interfaces, including those that are not secure.\n- **Do** bind your service to a specific IP address or network interface to limit access and enhance security. This can be achieved through various methods:\n    - Specify the IP address using an environment variable for flexible and secure configuration.\n    - Define the IP address in a configuration file that the application reads at startup.\n    - Dynamically identify the appropriate network interface and bind the service to its IP address.\n- **Do** implement security best practices when configuring network services. Use firewalls to control access and encrypt communication with TLS to protect data in transit.\n\n## References\n\n- [Go net package](https://pkg.go.dev/net)\n- [Go os package for environment variables](https://pkg.go.dev/os)","markdown":"## Description\n\nBinding a service to \"0.0.0.0\" makes it accessible on all network interfaces. This configuration can lead to unintended exposure over insecure or unintended network interfaces, creating potential security risks.\n\n## Remediations\n\n- **Do not** bind services to \"0.0.0.0\" without considering the security implications. This default setting can expose your service on all network interfaces, including those that are not secure.\n- **Do** bind your service to a specific IP address or network interface to limit access and enhance security. This can be achieved through various methods:\n    - Specify the IP address using an environment variable for flexible and secure configuration.\n    - Define the IP address in a configuration file that the application reads at startup.\n    - Dynamically identify the appropriate network interface and bind the service to its IP address.\n- **Do** implement security best practices when configuring network services. Use firewalls to control access and encrypt communication with TLS to protect data in transit.\n\n## References\n\n- [Go net package](https://pkg.go.dev/net)\n- [Go os package for environment variables](https://pkg.go.dev/os)"}},{"id":"go_lang_hardcoded_pg_database_password","name":"go_lang_hardcoded_pg_database_password","shortDescription":{"text":"Usage of hard-coded PostgreSQL database password"},"fullDescription":{"text":"Usage of hard-coded PostgreSQL database password"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nYour code contains a hard-coded password for connecting to a PostgreSQL database. Storing passwords directly in the code compromises security and makes your application vulnerable to unauthorized access.\n\n## Remediations\n\n- **Do not** embed passwords directly in your database connection strings or code. This practice exposes your database to potential security breaches.\n- **Do** use environment variables to store sensitive information such as database passwords. This method keeps credentials out of your codebase and makes them easier to manage securely.\n- **Do** consider implementing a key-management system to securely handle passwords and other sensitive information. This approach provides enhanced security measures for managing and accessing credentials.\n\n## References\n\n- [OWASP hardcoded passwords](https://owasp.org/www-community/vulnerabilities/Use_of_hard-coded_password)","markdown":"## Description\n\nYour code contains a hard-coded password for connecting to a PostgreSQL database. Storing passwords directly in the code compromises security and makes your application vulnerable to unauthorized access.\n\n## Remediations\n\n- **Do not** embed passwords directly in your database connection strings or code. This practice exposes your database to potential security breaches.\n- **Do** use environment variables to store sensitive information such as database passwords. This method keeps credentials out of your codebase and makes them easier to manage securely.\n- **Do** consider implementing a key-management system to securely handle passwords and other sensitive information. This approach provides enhanced security measures for managing and accessing credentials.\n\n## References\n\n- [OWASP hardcoded passwords](https://owasp.org/www-community/vulnerabilities/Use_of_hard-coded_password)"}},{"id":"go_gosec_blocklist_sha1","name":"go_gosec_blocklist_sha1","shortDescription":{"text":"Import of weak hashing library (SHA-1)"},"fullDescription":{"text":"Import of weak hashing library (SHA-1)"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nThe SHA-1 hashing algorithm is outdated and vulnerable to collision attacks, where two distinct inputs produce the same output hash. This flaw compromises the algorithm's ability to securely verify data integrity and authenticity, making it unsuitable for cryptographic security.\n\n## Remediations\n\n- **Do not** use SHA-1 for cryptographic purposes or to ensure data integrity. Its susceptibility to collision attacks poses a significant security risk.\n- **Do** use stronger hashing algorithms such as SHA-3 or BLAKE2 for general hashing purposes, such as file integrity checks or generating unique identifiers.\n- **Do** use recommended algorithms such as bcrypt or Argon2id for password hashing, as these are designed to be slower and therefore more effective against brute-force attacks.\n\n## References\n\n- [OWASP Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)\n- [NIST Policy on Hash Functions](https://csrc.nist.gov/projects/hash-functions)","markdown":"## Description\n\nThe SHA-1 hashing algorithm is outdated and vulnerable to collision attacks, where two distinct inputs produce the same output hash. This flaw compromises the algorithm's ability to securely verify data integrity and authenticity, making it unsuitable for cryptographic security.\n\n## Remediations\n\n- **Do not** use SHA-1 for cryptographic purposes or to ensure data integrity. Its susceptibility to collision attacks poses a significant security risk.\n- **Do** use stronger hashing algorithms such as SHA-3 or BLAKE2 for general hashing purposes, such as file integrity checks or generating unique identifiers.\n- **Do** use recommended algorithms such as bcrypt or Argon2id for password hashing, as these are designed to be slower and therefore more effective against brute-force attacks.\n\n## References\n\n- [OWASP Cryptographic Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)\n- [NIST Policy on Hash Functions](https://csrc.nist.gov/projects/hash-functions)"}},{"id":"go_third_parties_clickhouse","name":"go_third_parties_clickhouse","shortDescription":{"text":"Leakage of sensitive data to ClickHouse"},"fullDescription":{"text":"Leakage of sensitive data to ClickHouse"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to a third-party service like ClickHouse is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party services like ClickHouse.\n\n## References\n- [ClickHouse docs](https://clickhouse.com/docs/en/intro/)\n","markdown":"## Description\n\nLeaking sensitive data to a third-party service like ClickHouse is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party services like ClickHouse.\n\n## References\n- [ClickHouse docs](https://clickhouse.com/docs/en/intro/)\n"}},{"id":"go_gosec_filesystem_tempfile","name":"go_gosec_filesystem_tempfile","shortDescription":{"text":"Permissive temporary file creation"},"fullDescription":{"text":"Permissive temporary file creation"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nYour application creates temporary files in shared system directories like `/tmp` or `/var/tmp` without using secure functions such as `os.CreateTemp`. This method is risky as it could lead to symlink attacks. In such attacks, an attacker predicts the name of the temporary file and creates a symlink to a target file. Consequently, when your application writes to the supposed temporary file, it could unintentionally overwrite or create unauthorized files.\n\n## Remediations\n\n- **Do** use `os.CreateTemp` for creating temporary files. This function helps in securely generating temporary files within a directory that only your application can access, significantly reducing the risk of symlink attacks.\n  ```go\n  f, err := os.CreateTemp(restrictedDir, \"temp-*.txt\")\n  ```\n- **Do not** use shared temporary directories for operations that involve sensitive data or require secure file handling.\n- **Do** ensure temporary files are removed after their intended use to avoid accumulation and potential security risks.\n\n## References\n\n- [Go Documentation: os.CreateTemp](https://pkg.go.dev/os#CreateTemp)","markdown":"## Description\n\nYour application creates temporary files in shared system directories like `/tmp` or `/var/tmp` without using secure functions such as `os.CreateTemp`. This method is risky as it could lead to symlink attacks. In such attacks, an attacker predicts the name of the temporary file and creates a symlink to a target file. Consequently, when your application writes to the supposed temporary file, it could unintentionally overwrite or create unauthorized files.\n\n## Remediations\n\n- **Do** use `os.CreateTemp` for creating temporary files. This function helps in securely generating temporary files within a directory that only your application can access, significantly reducing the risk of symlink attacks.\n  ```go\n  f, err := os.CreateTemp(restrictedDir, \"temp-*.txt\")\n  ```\n- **Do not** use shared temporary directories for operations that involve sensitive data or require secure file handling.\n- **Do** ensure temporary files are removed after their intended use to avoid accumulation and potential security risks.\n\n## References\n\n- [Go Documentation: os.CreateTemp](https://pkg.go.dev/os#CreateTemp)"}},{"id":"go_gosec_injection_template_injection","name":"go_gosec_injection_template_injection","shortDescription":{"text":"Unsanitized user input in web page generation (XSS)"},"fullDescription":{"text":"Unsanitized user input in web page generation (XSS)"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nCross-Site Scripting (XSS) is a vulnerability that allows attackers to run malicious scripts in the context of a trusted web application. This can happen when an application includes untrusted data without proper validation or escaping. There are several contexts where XSS can occur, each requiring specific encoding strategies to mitigate the risk.\n\n## Remediations\n\n- **Do** encode user input based on the context it is used in, such as HTML content, HTML attributes, JavaScript, and CSS contexts. This helps prevent malicious scripts from being executed.\n  ```go\n  html.EscapeString(userInput)\n  ```\n- **Do** use templating engines like `html/template` that automatically encode data based on its context.\n- **Do** sanitize data using libraries or functions specifically designed for this purpose, especially when inserting content into a web page.\n- **Do** separate data from code by avoiding inline scripting and event handlers. Use separate JavaScript files for event handling to minimize script injection risks.\n- **Do not** mix server-side and client-side templating systems, as server-side systems may not escape output safely for client-side use.\n- **Do not** encode user input before storing it in a database. Any encoding should be applied when the data is output, not before storage, to ensure that it is encoded appropriately for its context.\n\n## References\n\n- [OWASP XSS Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)\n- [Go html/template Documentation](https://pkg.go.dev/html/template)","markdown":"## Description\n\nCross-Site Scripting (XSS) is a vulnerability that allows attackers to run malicious scripts in the context of a trusted web application. This can happen when an application includes untrusted data without proper validation or escaping. There are several contexts where XSS can occur, each requiring specific encoding strategies to mitigate the risk.\n\n## Remediations\n\n- **Do** encode user input based on the context it is used in, such as HTML content, HTML attributes, JavaScript, and CSS contexts. This helps prevent malicious scripts from being executed.\n  ```go\n  html.EscapeString(userInput)\n  ```\n- **Do** use templating engines like `html/template` that automatically encode data based on its context.\n- **Do** sanitize data using libraries or functions specifically designed for this purpose, especially when inserting content into a web page.\n- **Do** separate data from code by avoiding inline scripting and event handlers. Use separate JavaScript files for event handling to minimize script injection risks.\n- **Do not** mix server-side and client-side templating systems, as server-side systems may not escape output safely for client-side use.\n- **Do not** encode user input before storing it in a database. Any encoding should be applied when the data is output, not before storage, to ensure that it is encoded appropriately for its context.\n\n## References\n\n- [OWASP XSS Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)\n- [Go html/template Documentation](https://pkg.go.dev/html/template)"}},{"id":"go_third_parties_sentry","name":"go_third_parties_sentry","shortDescription":{"text":"Leakage of sensitive data to Sentry"},"fullDescription":{"text":"Leakage of sensitive data to Sentry"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to third-party loggers like Sentry is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party loggers like Sentry.\n\n## References\n- [Sentry Docs](https://docs.sentry.io/platforms/go/)\n","markdown":"## Description\n\nLeaking sensitive data to third-party loggers like Sentry is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party loggers like Sentry.\n\n## References\n- [Sentry Docs](https://docs.sentry.io/platforms/go/)\n"}},{"id":"go_third_parties_honeybadger","name":"go_third_parties_honeybadger","shortDescription":{"text":"Leakage of sensitive data to Honeybadger"},"fullDescription":{"text":"Leakage of sensitive data to Honeybadger"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to third-party loggers like Honeybadger is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party loggers like Honeybadger.\n\n## References\n- [Honeybadger Docs](https://docs.honeybadger.io/lib/go/)\n","markdown":"## Description\n\nLeaking sensitive data to third-party loggers like Honeybadger is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party loggers like Honeybadger.\n\n## References\n- [Honeybadger Docs](https://docs.honeybadger.io/lib/go/)\n"}},{"id":"go_lang_insecure_cookie","name":"go_lang_insecure_cookie","shortDescription":{"text":"Missing Secure option in cookie configuration"},"fullDescription":{"text":"Missing Secure option in cookie configuration"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nMissing the Secure option in cookie configuration can compromise cookie security. The Secure attribute, when set to true, ensures cookies are sent to the server only over HTTPS, protecting them from interception by unauthorized parties.\n\n## Remediations\n\n- **Do** set the `Secure` attribute for cookies to `true`. This ensures cookies are transmitted securely over HTTPS, preventing unauthorized access.\n  ```go\n  http.SetCookie(w, \u0026http.Cookie{\n      Name:     \"session_token\",\n      Value:    sessionToken,\n      Secure:   true,\n      // Additional flags like HttpOnly, SameSite, etc., should be set as needed.\n  })\n  ```\n- **Do** also set `HttpOnly`, `SameSite`, and `Domain` attributes for cookies as needed by your application. These attributes provide additional layers of security for your cookies.\n\n## References\n\n- [OWASP Secure Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)\n- [MDN Web Docs: HttpOnly Cookie Attribute](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies)","markdown":"## Description\n\nMissing the Secure option in cookie configuration can compromise cookie security. The Secure attribute, when set to true, ensures cookies are sent to the server only over HTTPS, protecting them from interception by unauthorized parties.\n\n## Remediations\n\n- **Do** set the `Secure` attribute for cookies to `true`. This ensures cookies are transmitted securely over HTTPS, preventing unauthorized access.\n  ```go\n  http.SetCookie(w, \u0026http.Cookie{\n      Name:     \"session_token\",\n      Value:    sessionToken,\n      Secure:   true,\n      // Additional flags like HttpOnly, SameSite, etc., should be set as needed.\n  })\n  ```\n- **Do** also set `HttpOnly`, `SameSite`, and `Domain` attributes for cookies as needed by your application. These attributes provide additional layers of security for your cookies.\n\n## References\n\n- [OWASP Secure Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)\n- [MDN Web Docs: HttpOnly Cookie Attribute](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies)"}},{"id":"go_gorilla_cookie_missing_http_only","name":"go_gorilla_cookie_missing_http_only","shortDescription":{"text":"Missing HTTP Only option in cookie configuration"},"fullDescription":{"text":"Missing HTTP Only option in cookie configuration"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nThe absence of the \"HttpOnly\" attribute in cookie settings leaves the cookie vulnerable to being accessed by client-side JavaScript, such as through \"document.cookie\". This vulnerability is particularly concerning for websites susceptible to Cross-Site Scripting (XSS) attacks, as it allows malicious scripts to read the cookie value. Properly configuring the \"HttpOnly\" attribute is a critical step in securing cookies, especially for session management.\n\n## Remediations\n\n- **Do** set the `HttpOnly` attribute to `true` for cookies, especially session cookies, to prevent them from being accessed by client-side scripts. This is a key measure in mitigating the risk of XSS attacks.\n  ```go\n  func MyHandler(w http.ResponseWriter, r *http.Request) {\n      session, _ := store.Get(r, \"session-name\")\n      ...\n      session.Options.HttpOnly = true\n      session.Save(r, w)\n  }\n  ```\n- **Do** use Gorilla SecureCookie for encoding and decoding session data securely. This method provides an additional layer of security for session information.\n  ```go\n  var s = sessions.NewCookieStore([]byte(\"your-secret-key\"))\n  ```\n- **Do** implement robust session management with Gorilla Sessions. Proper session management helps prevent attacks related to session fixation and enhances overall session security.\n\n## References\n\n- [Gorilla Sessions Documentation](http://www.gorillatoolkit.org/pkg/sessions)\n- [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)\n- [OWASP Cookies Properties](https://owasp.org/www-community/controls/SecureCookieAttribute)","markdown":"## Description\n\nThe absence of the \"HttpOnly\" attribute in cookie settings leaves the cookie vulnerable to being accessed by client-side JavaScript, such as through \"document.cookie\". This vulnerability is particularly concerning for websites susceptible to Cross-Site Scripting (XSS) attacks, as it allows malicious scripts to read the cookie value. Properly configuring the \"HttpOnly\" attribute is a critical step in securing cookies, especially for session management.\n\n## Remediations\n\n- **Do** set the `HttpOnly` attribute to `true` for cookies, especially session cookies, to prevent them from being accessed by client-side scripts. This is a key measure in mitigating the risk of XSS attacks.\n  ```go\n  func MyHandler(w http.ResponseWriter, r *http.Request) {\n      session, _ := store.Get(r, \"session-name\")\n      ...\n      session.Options.HttpOnly = true\n      session.Save(r, w)\n  }\n  ```\n- **Do** use Gorilla SecureCookie for encoding and decoding session data securely. This method provides an additional layer of security for session information.\n  ```go\n  var s = sessions.NewCookieStore([]byte(\"your-secret-key\"))\n  ```\n- **Do** implement robust session management with Gorilla Sessions. Proper session management helps prevent attacks related to session fixation and enhances overall session security.\n\n## References\n\n- [Gorilla Sessions Documentation](http://www.gorillatoolkit.org/pkg/sessions)\n- [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)\n- [OWASP Cookies Properties](https://owasp.org/www-community/controls/SecureCookieAttribute)"}},{"id":"go_gosec_unsafe_unsafe","name":"go_gosec_unsafe_unsafe","shortDescription":{"text":"Usage of vulnerable 'unsafe' package"},"fullDescription":{"text":"Usage of vulnerable 'unsafe' package"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nThe `unsafe` package in Go allows for low-level memory management, including direct memory access and pointer manipulation. While `unsafe` is a powerful library, using it bypasses Go's type safety checks and opens the door to security vulnerabilities and unpredictable behavior in your application.\n\n## Remediations\n\n- **Do not** use the `unsafe` package unless it is absolutely necessary. If you must use it, ensure you fully understand the implications and thoroughly test your code.\n- **Do** ensure buffer boundaries are respected to avoid buffer overflows. This precaution helps prevent unauthorized code execution.\n  ```go\n  buffer := make([]byte, 10)\n  ```\n- **Do not** access memory after it has been freed to avoid use-after-free vulnerabilities, which can lead to unintended code execution or unpredictable system behavior.\n  ```go\n  unsafePointer := unsafe.Pointer(\u0026data)\n  C.free(unsafePointer)\n  // now unsafe to access\n  ```\n- **Do** regularly review and audit your code to prevent memory or information leaks that could compromise security or lead to system failures due to exhausted memory.\n\n## References\n\n- [Buffer Overflows - OWASP](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow)\n- [Using Freed Memory - OWASP](https://owasp.org/www-community/vulnerabilities/Using_freed_memory)\n- [Memory Leaks - OWASP](https://owasp.org/www-community/vulnerabilities/Memory_leak)","markdown":"## Description\n\nThe `unsafe` package in Go allows for low-level memory management, including direct memory access and pointer manipulation. While `unsafe` is a powerful library, using it bypasses Go's type safety checks and opens the door to security vulnerabilities and unpredictable behavior in your application.\n\n## Remediations\n\n- **Do not** use the `unsafe` package unless it is absolutely necessary. If you must use it, ensure you fully understand the implications and thoroughly test your code.\n- **Do** ensure buffer boundaries are respected to avoid buffer overflows. This precaution helps prevent unauthorized code execution.\n  ```go\n  buffer := make([]byte, 10)\n  ```\n- **Do not** access memory after it has been freed to avoid use-after-free vulnerabilities, which can lead to unintended code execution or unpredictable system behavior.\n  ```go\n  unsafePointer := unsafe.Pointer(\u0026data)\n  C.free(unsafePointer)\n  // now unsafe to access\n  ```\n- **Do** regularly review and audit your code to prevent memory or information leaks that could compromise security or lead to system failures due to exhausted memory.\n\n## References\n\n- [Buffer Overflows - OWASP](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow)\n- [Using Freed Memory - OWASP](https://owasp.org/www-community/vulnerabilities/Using_freed_memory)\n- [Memory Leaks - OWASP](https://owasp.org/www-community/vulnerabilities/Memory_leak)"}},{"id":"go_third_parties_bigquery","name":"go_third_parties_bigquery","shortDescription":{"text":"Leakage of sensitive data to BigQuery"},"fullDescription":{"text":"Leakage of sensitive data to BigQuery"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to third-party data tools like BigQuery is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party services like BigQuery.\n\n## References\n- [BigQuery package](https://pkg.go.dev/cloud.google.com/go/bigquery)\n","markdown":"## Description\n\nLeaking sensitive data to third-party data tools like BigQuery is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party services like BigQuery.\n\n## References\n- [BigQuery package](https://pkg.go.dev/cloud.google.com/go/bigquery)\n"}},{"id":"go_lang_logger_leak","name":"go_lang_logger_leak","shortDescription":{"text":"Leakage of information in logger message"},"fullDescription":{"text":"Leakage of information in logger message"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nInformation leakage through logger messages can result in data breaches. This vulnerability arises when dynamic data or variables, which may contain sensitive information, are included in log messages.\n\n## Remediations\n\n- **Do not** include variables or dynamic data containing sensitive information in logger messages. This can inadvertently expose sensitive data.\n  ```go\n  logger.info(f\"User is: '{user.email}'\") // unsafe\n  ```\n- **Do** sanitize or remove sensitive information from data before logging. Ensure that logged information does not contain any personal or confidential data.","markdown":"## Description\n\nInformation leakage through logger messages can result in data breaches. This vulnerability arises when dynamic data or variables, which may contain sensitive information, are included in log messages.\n\n## Remediations\n\n- **Do not** include variables or dynamic data containing sensitive information in logger messages. This can inadvertently expose sensitive data.\n  ```go\n  logger.info(f\"User is: '{user.email}'\") // unsafe\n  ```\n- **Do** sanitize or remove sensitive information from data before logging. Ensure that logged information does not contain any personal or confidential data."}},{"id":"go_gosec_file_permissions_mkdir","name":"go_gosec_file_permissions_mkdir","shortDescription":{"text":"Permissive folder creation"},"fullDescription":{"text":"Permissive folder creation"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nIncorrect directory permissions can severely compromise system security.Directories with overly permissive access rights can allow unauthorized users to manipulate files, potentially leading to malicious code execution, data breaches, or full system compromise.\n\n## Remediations\n\n- **Do not** use overly broad permissions like `0777` for directories, as this allows all users to read, write, and execute files, posing a significant security risk.\n  ```go\n  os.Mkdir(\"example_directory\", 0777) // unsafe\n  ```\n- **Do** set directory permissions to:\n  - `0700` for private user data, granting full control to the owner only.\n  - `0750` for directories requiring group access, granting full control to the owner and read/execute to the group.\n  ```go\n  os.Mkdir(\"secure_directory\", 0700)\n  ```\n- **Do** verify file permissions after creation or update to ensure they are set as intended.\n- **Do** consider setting umask to a secure default, if your application creates multiple files, to ensure that files are created with safe default permissions.\n- **Do** regularly review and audit file permissions in your system to ensure they adhere to the principle of least privilege, minimizing the access level to what is strictly necessary for operational functionality.","markdown":"## Description\n\nIncorrect directory permissions can severely compromise system security.Directories with overly permissive access rights can allow unauthorized users to manipulate files, potentially leading to malicious code execution, data breaches, or full system compromise.\n\n## Remediations\n\n- **Do not** use overly broad permissions like `0777` for directories, as this allows all users to read, write, and execute files, posing a significant security risk.\n  ```go\n  os.Mkdir(\"example_directory\", 0777) // unsafe\n  ```\n- **Do** set directory permissions to:\n  - `0700` for private user data, granting full control to the owner only.\n  - `0750` for directories requiring group access, granting full control to the owner and read/execute to the group.\n  ```go\n  os.Mkdir(\"secure_directory\", 0700)\n  ```\n- **Do** verify file permissions after creation or update to ensure they are set as intended.\n- **Do** consider setting umask to a secure default, if your application creates multiple files, to ensure that files are created with safe default permissions.\n- **Do** regularly review and audit file permissions in your system to ensure they adhere to the principle of least privilege, minimizing the access level to what is strictly necessary for operational functionality."}},{"id":"go_lang_logger","name":"go_lang_logger","shortDescription":{"text":"Leakage of sensitive information in logger message"},"fullDescription":{"text":"Leakage of sensitive information in logger message"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeakage of sensitive information in logger messages can compromise data security. This vulnerability arises when sensitive data is included in log messages, potentially leading to unauthorized access.\n\n## Remediations\n\n- **Do not** include sensitive data, such as email addresses, in logger messages. This can inadvertently expose personal information.\n  ```go\n  logger.info(f\"User is: '{user.email}'\") // unsafe\n  ```\n- **Do** use non-sensitive, unique identifiers, like user UUIDs, in logger messages to maintain user privacy and data security.\n  ```go\n  logger.info(f\"User is: '{user.uuid}'\")\n  ```\n\n## References\n\n- [OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)","markdown":"## Description\n\nLeakage of sensitive information in logger messages can compromise data security. This vulnerability arises when sensitive data is included in log messages, potentially leading to unauthorized access.\n\n## Remediations\n\n- **Do not** include sensitive data, such as email addresses, in logger messages. This can inadvertently expose personal information.\n  ```go\n  logger.info(f\"User is: '{user.email}'\") // unsafe\n  ```\n- **Do** use non-sensitive, unique identifiers, like user UUIDs, in logger messages to maintain user privacy and data security.\n  ```go\n  logger.info(f\"User is: '{user.uuid}'\")\n  ```\n\n## References\n\n- [OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)"}},{"id":"go_lang_hardcoded_mysql_database_password","name":"go_lang_hardcoded_mysql_database_password","shortDescription":{"text":"Usage of hard-coded MySQL database password"},"fullDescription":{"text":"Usage of hard-coded MySQL database password"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nYour code contains a hard-coded password for MySQL database connections. Storing passwords directly in code compromises security and makes your application vulnerable to unauthorized access.\n\n## Remediations\n\n- **Do not** embed passwords directly in your code. This practice is insecure and exposes your database to potential breaches.\n- **Do** use environment variables to store sensitive information such as database passwords. This method keeps credentials out of your codebase and makes them easier to manage securely.\n- **Do** consider implementing a key-management system to securely handle passwords and other sensitive information. This approach provides enhanced security measures for managing and accessing credentials.\n\n## References\n\n- [OWASP hardcoded passwords](https://owasp.org/www-community/vulnerabilities/Use_of_hard-coded_password)","markdown":"## Description\n\nYour code contains a hard-coded password for MySQL database connections. Storing passwords directly in code compromises security and makes your application vulnerable to unauthorized access.\n\n## Remediations\n\n- **Do not** embed passwords directly in your code. This practice is insecure and exposes your database to potential breaches.\n- **Do** use environment variables to store sensitive information such as database passwords. This method keeps credentials out of your codebase and makes them easier to manage securely.\n- **Do** consider implementing a key-management system to securely handle passwords and other sensitive information. This approach provides enhanced security measures for managing and accessing credentials.\n\n## References\n\n- [OWASP hardcoded passwords](https://owasp.org/www-community/vulnerabilities/Use_of_hard-coded_password)"}},{"id":"go_gosec_filesystem_dirtraversal","name":"go_gosec_filesystem_dirtraversal","shortDescription":{"text":"Usage of Root directory mounting"},"fullDescription":{"text":"Usage of Root directory mounting"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nMounting the root directory (`/`) on an HTTP server exposes a significant security risk. This setup could allow unauthorized individuals to access and browse system files, potentially leading to information disclosure, data breaches, or further system exploitation.\n\n## Remediations\n\n- **Do not** mount the root directory as the web server's root. Doing so would make the entire filesystem accessible over the web.\n- **Do** serve files from a specific directory designed for public access. Ensure this directory only contains files intended for public viewing.\n- **Do** apply strict permissions to the directory being served. This ensures the server process accesses only the files it's meant to serve.\n- **Do** utilize server configuration files, such as `.htaccess` for Apache HTTP Server, to control access to directories if your server supports it.\n- **Do** consider isolating your server environment using containerization or virtualization techniques. This limits potential damage in case of a security breach by enforcing strict access controls.\n- **Do** conduct regular audits of your filesystem and the files your server is hosting. This helps ensure no sensitive information is accidentally exposed.\n\n## References\n\n- [Go Documentation: http package](https://pkg.go.dev/net/http)\n- [OWASP: Securing File Uploads](https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload)\n- [NIST Guidelines on Securing Public Web Servers](https://csrc.nist.gov/publications/detail/sp/800-44/version-2/final)\n- [Docker Documentation: Use containers for isolation](https://docs.docker.com/get-started/overview/#use-containers-for-isolation)\n- [Linux man page for chmod (file permissions)](https://linux.die.net/man/1/chmod)","markdown":"## Description\n\nMounting the root directory (`/`) on an HTTP server exposes a significant security risk. This setup could allow unauthorized individuals to access and browse system files, potentially leading to information disclosure, data breaches, or further system exploitation.\n\n## Remediations\n\n- **Do not** mount the root directory as the web server's root. Doing so would make the entire filesystem accessible over the web.\n- **Do** serve files from a specific directory designed for public access. Ensure this directory only contains files intended for public viewing.\n- **Do** apply strict permissions to the directory being served. This ensures the server process accesses only the files it's meant to serve.\n- **Do** utilize server configuration files, such as `.htaccess` for Apache HTTP Server, to control access to directories if your server supports it.\n- **Do** consider isolating your server environment using containerization or virtualization techniques. This limits potential damage in case of a security breach by enforcing strict access controls.\n- **Do** conduct regular audits of your filesystem and the files your server is hosting. This helps ensure no sensitive information is accidentally exposed.\n\n## References\n\n- [Go Documentation: http package](https://pkg.go.dev/net/http)\n- [OWASP: Securing File Uploads](https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload)\n- [NIST Guidelines on Securing Public Web Servers](https://csrc.nist.gov/publications/detail/sp/800-44/version-2/final)\n- [Docker Documentation: Use containers for isolation](https://docs.docker.com/get-started/overview/#use-containers-for-isolation)\n- [Linux man page for chmod (file permissions)](https://linux.die.net/man/1/chmod)"}},{"id":"go_third_parties_segment","name":"go_third_parties_segment","shortDescription":{"text":"Leakage of sensitive data to Segment"},"fullDescription":{"text":"Leakage of sensitive data to Segment"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to third-party analytics tools like Segment is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party analytics libraries like Segment.\n\n## References\n- [Segment docs](https://segment.com/docs/connections/sources/catalog/libraries/server/go/)\n","markdown":"## Description\n\nLeaking sensitive data to third-party analytics tools like Segment is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party analytics libraries like Segment.\n\n## References\n- [Segment docs](https://segment.com/docs/connections/sources/catalog/libraries/server/go/)\n"}},{"id":"go_gosec_http_http_serve","name":"go_gosec_http_http_serve","shortDescription":{"text":"Usage of vulnerable 'serve' function"},"fullDescription":{"text":"Usage of vulnerable 'serve' function"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nThe default `serve` functions in Go's `net/http` package are susceptible to resource consumption attacks. This vulnerability arises when attackers flood the server with incomplete or persistent connections, depleting its resources and blocking new legitimate connections.\n\n## Remediations\n\n- **Do not** use default serve functions like `http.ListenAndServe` and `http.Serve` in production environments. You cannot set timeouts for these functions, making the server vulnerable to attacks.\n  ```go\n  http.ListenAndServe(\":8080\", nil) // unsafe\n  ```\n- **Do** create a custom `http.Server` object with configured timeouts to safeguard against resource exhaustion. Set `ReadHeaderTimeout`, `ReadTimeout`, `WriteTimeout`, and `IdleTimeout` to appropriate values.\n  ```go\n  myServer := \u0026http.Server{\n      Addr:             \"localhost:8000\",\n      ReadHeaderTimeout: 15 * time.Second,\n      ReadTimeout:      15 * time.Second,\n      WriteTimeout:     10 * time.Second,\n      IdleTimeout:      30 * time.Second,\n  }\n  ```\n- **Do** enforce timeouts on individual requests using `http.TimeoutHandler`. This wrapper ensures that the server does not indefinitely wait for a request to finish, preventing potential denial of service.\n\n## References\n\n- [http.Server Timeouts Documentation](https://pkg.go.dev/net/http#Server)\n- [Guide to Setting Request-Based Timeouts](https://pkg.go.dev/net/http#TimeoutHandler)\n- [Understanding the Slowloris Attack](https://en.wikipedia.org/wiki/Slowloris_(computer_security))","markdown":"## Description\n\nThe default `serve` functions in Go's `net/http` package are susceptible to resource consumption attacks. This vulnerability arises when attackers flood the server with incomplete or persistent connections, depleting its resources and blocking new legitimate connections.\n\n## Remediations\n\n- **Do not** use default serve functions like `http.ListenAndServe` and `http.Serve` in production environments. You cannot set timeouts for these functions, making the server vulnerable to attacks.\n  ```go\n  http.ListenAndServe(\":8080\", nil) // unsafe\n  ```\n- **Do** create a custom `http.Server` object with configured timeouts to safeguard against resource exhaustion. Set `ReadHeaderTimeout`, `ReadTimeout`, `WriteTimeout`, and `IdleTimeout` to appropriate values.\n  ```go\n  myServer := \u0026http.Server{\n      Addr:             \"localhost:8000\",\n      ReadHeaderTimeout: 15 * time.Second,\n      ReadTimeout:      15 * time.Second,\n      WriteTimeout:     10 * time.Second,\n      IdleTimeout:      30 * time.Second,\n  }\n  ```\n- **Do** enforce timeouts on individual requests using `http.TimeoutHandler`. This wrapper ensures that the server does not indefinitely wait for a request to finish, preventing potential denial of service.\n\n## References\n\n- [http.Server Timeouts Documentation](https://pkg.go.dev/net/http#Server)\n- [Guide to Setting Request-Based Timeouts](https://pkg.go.dev/net/http#TimeoutHandler)\n- [Understanding the Slowloris Attack](https://en.wikipedia.org/wiki/Slowloris_(computer_security))"}},{"id":"go_third_parties_google_analytics","name":"go_third_parties_google_analytics","shortDescription":{"text":"Leakage of sensitive data to Google Analytics"},"fullDescription":{"text":"Leakage of sensitive data to Google Analytics"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to third-party analytics tools like Google Analytics is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to analytics libraries like Google Analytics.\n\n ## References\n- [Google Analytics docs](https://developers.google.com/analytics/devguides/reporting/)\n","markdown":"## Description\n\nLeaking sensitive data to third-party analytics tools like Google Analytics is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to analytics libraries like Google Analytics.\n\n ## References\n- [Google Analytics docs](https://developers.google.com/analytics/devguides/reporting/)\n"}},{"id":"go_third_parties_elasticsearch","name":"go_third_parties_elasticsearch","shortDescription":{"text":"Leakage of sensitive data to ElasticSearch"},"fullDescription":{"text":"Leakage of sensitive data to ElasticSearch"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to third-party data tools is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party services like ElasticSearch\n\n## References\n- [Elasticsearch docs](https://www.elastic.co/guide/en/elasticsearch/client/go-api/current/index.html)\n","markdown":"## Description\n\nLeaking sensitive data to third-party data tools is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third-party services like ElasticSearch\n\n## References\n- [Elasticsearch docs](https://www.elastic.co/guide/en/elasticsearch/client/go-api/current/index.html)\n"}},{"id":"go_gosec_memory_integer_overflow","name":"go_gosec_memory_integer_overflow","shortDescription":{"text":"Possible integer overflow"},"fullDescription":{"text":"Possible integer overflow"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nIn Go, the size of an `int` type is not fixed and depends on the system architecture (32 bits on a 32-bit system and 64 bits on a 64-bit system). This can lead to integer overflow when a value is converted from `strconv.Atoi` to a smaller integer type like `int32` or `int16`, and the value exceeds what the smaller type can hold. Integer overflow can result in unpredictable behavior and severe bugs.\n\n## Remediations\n\n- **Do** check values before conversion to a smaller type. Ensure the value does not exceed the maximum value the target type can hold.\n- **Do** always handle errors from conversion functions like `strconv.Atoi` to promptly address and manage conversion issues.\n- **Do** use fixed-size types like `int32` or `int64` when possible to avoid overflow issues that arise from architecture-dependent sizes.\n  ```go\n    if intValue, err := strconv.Atoi(stringValue); err == nil {\n      if intValue \u003e= math.MinInt16 \u0026\u0026 intValue \u003c= math.MaxInt16 {\n        int16Value := int16(intValue)\n      }\n    }\n  ```\n\n## References\n\n- [Go math package for integer limits](https://pkg.go.dev/math#pkg-constants)","markdown":"## Description\n\nIn Go, the size of an `int` type is not fixed and depends on the system architecture (32 bits on a 32-bit system and 64 bits on a 64-bit system). This can lead to integer overflow when a value is converted from `strconv.Atoi` to a smaller integer type like `int32` or `int16`, and the value exceeds what the smaller type can hold. Integer overflow can result in unpredictable behavior and severe bugs.\n\n## Remediations\n\n- **Do** check values before conversion to a smaller type. Ensure the value does not exceed the maximum value the target type can hold.\n- **Do** always handle errors from conversion functions like `strconv.Atoi` to promptly address and manage conversion issues.\n- **Do** use fixed-size types like `int32` or `int64` when possible to avoid overflow issues that arise from architecture-dependent sizes.\n  ```go\n    if intValue, err := strconv.Atoi(stringValue); err == nil {\n      if intValue \u003e= math.MinInt16 \u0026\u0026 intValue \u003c= math.MaxInt16 {\n        int16Value := int16(intValue)\n      }\n    }\n  ```\n\n## References\n\n- [Go math package for integer limits](https://pkg.go.dev/math#pkg-constants)"}},{"id":"go_lang_weak_hash_sha1","name":"go_lang_weak_hash_sha1","shortDescription":{"text":"Usage of weak hashing library (SHA-1)"},"fullDescription":{"text":"Usage of weak hashing library (SHA-1)"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nUsing a weak hashing library such as SHA-1 can compromise data security. SHA-1 is no longer considered secure due to vulnerabilities that can lead to data breaches.\n\n## Remediations\n\n- **Do not** use SHA-1 for hashing. It is considered weak and vulnerable to attacks.\n  ```go\n  sha1.Sum([]byte(\"password\")) // unsafe\n  ```\n- **Do** use stronger hashing algorithms such as SHA-256 to enhance security.\n  ```go\n  sha256.Sum256([]byte(\"string\"))\n  ```","markdown":"## Description\n\nUsing a weak hashing library such as SHA-1 can compromise data security. SHA-1 is no longer considered secure due to vulnerabilities that can lead to data breaches.\n\n## Remediations\n\n- **Do not** use SHA-1 for hashing. It is considered weak and vulnerable to attacks.\n  ```go\n  sha1.Sum([]byte(\"password\")) // unsafe\n  ```\n- **Do** use stronger hashing algorithms such as SHA-256 to enhance security.\n  ```go\n  sha256.Sum256([]byte(\"string\"))\n  ```"}},{"id":"go_gosec_crypto_weak_random","name":"go_gosec_crypto_weak_random","shortDescription":{"text":"Usage of weak Pseudo-Random Number Generator (PRNG)"},"fullDescription":{"text":"Usage of weak Pseudo-Random Number Generator (PRNG)"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nThe `math/rand` package in Go generates pseudorandom numbers that are not secure for cryptographic purposes. These numbers can be predicted if the seed is known, posing a risk to the security of applications that use them for generating secrets, tokens, or other security-sensitive elements.\n\n## Remediations\n\n- **Do** use `crypto/rand` instead of `math/rand` for generating random numbers in contexts where security is crucial. This ensures the randomness is cryptographically secure and unpredictable.\n- **Do not** use `math/rand` for generating random numbers in cryptographic applications, including but not limited to key generation, authentication tokens, or security challenges.\n- **Do not** initialize `math/rand` with predictable seeds, such as timestamps or other easily guessable values, if it is required to use `math/rand`.\n\n## References\n\n- [crypto/rand package documentation](https://pkg.go.dev/crypto/rand)","markdown":"## Description\n\nThe `math/rand` package in Go generates pseudorandom numbers that are not secure for cryptographic purposes. These numbers can be predicted if the seed is known, posing a risk to the security of applications that use them for generating secrets, tokens, or other security-sensitive elements.\n\n## Remediations\n\n- **Do** use `crypto/rand` instead of `math/rand` for generating random numbers in contexts where security is crucial. This ensures the randomness is cryptographically secure and unpredictable.\n- **Do not** use `math/rand` for generating random numbers in cryptographic applications, including but not limited to key generation, authentication tokens, or security challenges.\n- **Do not** initialize `math/rand` with predictable seeds, such as timestamps or other easily guessable values, if it is required to use `math/rand`.\n\n## References\n\n- [crypto/rand package documentation](https://pkg.go.dev/crypto/rand)"}},{"id":"go_lang_observable_timing","name":"go_lang_observable_timing","shortDescription":{"text":"Observable Timing Discrepancy"},"fullDescription":{"text":"Observable Timing Discrepancy"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nObservable Timing Discrepancy occurs when the time it takes for certain operations to complete can be measured and observed by attackers. This vulnerability is particularly concerning when operations involve sensitive information, such as password checks or secret comparisons. If attackers can analyze how long these operations take, they might be able to deduce confidential details, putting your data at risk.\n\n## Remediations\n\n- **Do** implement algorithms that process sensitive information, such as password checks, to run in constant time. This approach helps in mitigating timing attacks by ensuring that operations take the same amount of time regardless of the input.\n- **Do** use built-in cryptographic libraries that offer functions safe against timing attacks for comparing secret values. These libraries are designed to prevent timing discrepancies that could leak sensitive information.\n- **Do not** use direct string comparisons for sensitive information. This method can result in early termination of the comparison function, leading to timing discrepancies based on the first mismatched character.\n- **Do not** design application logic that alters execution paths in a manner that could introduce observable timing differences, particularly when processing user input or comparing secret values.\n\n## References\n\n- [OWASP Guide to Cryptography](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)","markdown":"## Description\n\nObservable Timing Discrepancy occurs when the time it takes for certain operations to complete can be measured and observed by attackers. This vulnerability is particularly concerning when operations involve sensitive information, such as password checks or secret comparisons. If attackers can analyze how long these operations take, they might be able to deduce confidential details, putting your data at risk.\n\n## Remediations\n\n- **Do** implement algorithms that process sensitive information, such as password checks, to run in constant time. This approach helps in mitigating timing attacks by ensuring that operations take the same amount of time regardless of the input.\n- **Do** use built-in cryptographic libraries that offer functions safe against timing attacks for comparing secret values. These libraries are designed to prevent timing discrepancies that could leak sensitive information.\n- **Do not** use direct string comparisons for sensitive information. This method can result in early termination of the comparison function, leading to timing discrepancies based on the first mismatched character.\n- **Do not** design application logic that alters execution paths in a manner that could introduce observable timing differences, particularly when processing user input or comparing secret values.\n\n## References\n\n- [OWASP Guide to Cryptography](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)"}},{"id":"go_lang_ssl_verification","name":"go_lang_ssl_verification","shortDescription":{"text":"Missing SSL certificate verification"},"fullDescription":{"text":"Missing SSL certificate verification"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nYour application's security is compromised if it fails to verify SSL certificates. This vulnerability occurs when your application communicates over HTTPS without validating the authenticity of the SSL certificate presented by the server. It exposes sensitive data to interception by attackers.\n\n## Remediations\n\n- **Do not** disable SSL certificate validation in your HTTP client. Disabling it makes your application vulnerable to Man-in-the-Middle (MitM) attacks.\n- **Do** ensure that your HTTP client is configured to verify both the SSL certificate's validity and the hostname. This step is crucial for establishing a secure connection.","markdown":"## Description\n\nYour application's security is compromised if it fails to verify SSL certificates. This vulnerability occurs when your application communicates over HTTPS without validating the authenticity of the SSL certificate presented by the server. It exposes sensitive data to interception by attackers.\n\n## Remediations\n\n- **Do not** disable SSL certificate validation in your HTTP client. Disabling it makes your application vulnerable to Man-in-the-Middle (MitM) attacks.\n- **Do** ensure that your HTTP client is configured to verify both the SSL certificate's validity and the hostname. This step is crucial for establishing a secure connection."}},{"id":"go_gosec_crypto_weak_crypto","name":"go_gosec_crypto_weak_crypto","shortDescription":{"text":"Usage of weak hashing library"},"fullDescription":{"text":"Usage of weak hashing library"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nYour code uses a weak hashing library, which means it relies on cryptographic algorithms that are no longer secure. This vulnerability can lead to compromised data confidentiality and integrity, as it makes the data susceptible to unauthorized decryption and tampering.\n\n## Remediations\n\n- **Do** replace weak or outdated algorithms with strong, modern alternatives. For encryption, use AES (Advanced Encryption Standard), and for hashing, opt for SHA-256 or higher.\n- **Do** always use the latest versions of cryptographic libraries. These versions are more likely to use secure algorithms and settings by default.\n- **Do not** use cryptographic algorithms that have been deprecated due to known vulnerabilities. Avoid MD5, SHA-1, or DES for any cryptographic operations.\n- **Do not** attempt to create custom cryptographic solutions. Instead use well-reviewed and tested standard cryptographic libraries to ensure security.\n\n## References\n\n- [NIST Cryptographic Standards and Guidelines](https://csrc.nist.gov/publications/sp)\n- [Cryptography Coding Standard](https://cryptocoding.net/index.php/Coding_rules)","markdown":"## Description\n\nYour code uses a weak hashing library, which means it relies on cryptographic algorithms that are no longer secure. This vulnerability can lead to compromised data confidentiality and integrity, as it makes the data susceptible to unauthorized decryption and tampering.\n\n## Remediations\n\n- **Do** replace weak or outdated algorithms with strong, modern alternatives. For encryption, use AES (Advanced Encryption Standard), and for hashing, opt for SHA-256 or higher.\n- **Do** always use the latest versions of cryptographic libraries. These versions are more likely to use secure algorithms and settings by default.\n- **Do not** use cryptographic algorithms that have been deprecated due to known vulnerabilities. Avoid MD5, SHA-1, or DES for any cryptographic operations.\n- **Do not** attempt to create custom cryptographic solutions. Instead use well-reviewed and tested standard cryptographic libraries to ensure security.\n\n## References\n\n- [NIST Cryptographic Standards and Guidelines](https://csrc.nist.gov/publications/sp)\n- [Cryptography Coding Standard](https://cryptocoding.net/index.php/Coding_rules)"}},{"id":"go_gosec_blocklist_md5","name":"go_gosec_blocklist_md5","shortDescription":{"text":"Import of weak hashing library (MD5)"},"fullDescription":{"text":"Import of weak hashing library (MD5)"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nUsing a weak hashing library like MD5 increases the risk of data breaches. MD5 is vulnerable to collision attacks, where two different inputs produce the same output, compromising data integrity and security.\n\n## Remediations\n\n- **Do not** use MD5 for hashing. It is considered a weak hash algorithm and can compromise data security.\n- **Do** use stronger hashing algorithms such as SHA-3 or BLAKE2 for general hashing purposes, such as file integrity checks or generating unique identifiers.\n- **Do** use recommended algorithms such as bcrypt or Argon2id for password hashing, as these are designed to be slower and therefore more effective against brute-force attacks.\n\n## References\n\n- [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)","markdown":"## Description\n\nUsing a weak hashing library like MD5 increases the risk of data breaches. MD5 is vulnerable to collision attacks, where two different inputs produce the same output, compromising data integrity and security.\n\n## Remediations\n\n- **Do not** use MD5 for hashing. It is considered a weak hash algorithm and can compromise data security.\n- **Do** use stronger hashing algorithms such as SHA-3 or BLAKE2 for general hashing purposes, such as file integrity checks or generating unique identifiers.\n- **Do** use recommended algorithms such as bcrypt or Argon2id for password hashing, as these are designed to be slower and therefore more effective against brute-force attacks.\n\n## References\n\n- [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)"}},{"id":"go_gosec_crypto_insecure_ignore_host_key","name":"go_gosec_crypto_insecure_ignore_host_key","shortDescription":{"text":"Missing verification of host keys"},"fullDescription":{"text":"Missing verification of host keys"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLacking verification of host key during SSH connections compromises the security of your application. Host keys are essential for verifying the server's identity to prevent Man-in-the-Middle (MitM) attacks, where an attacker could pose as the server. Without this verification, there's no way to ensure the server's authenticity.\n\n## Remediations\n\n- **Do not** use `ssh.InsecureIgnoreHostKey` as a `HostKeyCallback` function. This method bypasses any form of host validation, making your application vulnerable to attacks.\n- **Do** implement host key verification. For example, use the `knownhosts` package from Go's `x/crypto/ssh` to check server keys against a list of known hosts, similar to OpenSSH's approach.\n- **Do not** disable host key checking in your production code. While it might seem convenient for development or testing environments, it significantly increases the risk of security breaches.\n\n## References\n\n- [GoDoc for x/crypto/ssh](https://pkg.go.dev/golang.org/x/crypto/ssh)\n- [Secure use of SSH - OpenSSH](https://www.openssh.com/)","markdown":"## Description\n\nLacking verification of host key during SSH connections compromises the security of your application. Host keys are essential for verifying the server's identity to prevent Man-in-the-Middle (MitM) attacks, where an attacker could pose as the server. Without this verification, there's no way to ensure the server's authenticity.\n\n## Remediations\n\n- **Do not** use `ssh.InsecureIgnoreHostKey` as a `HostKeyCallback` function. This method bypasses any form of host validation, making your application vulnerable to attacks.\n- **Do** implement host key verification. For example, use the `knownhosts` package from Go's `x/crypto/ssh` to check server keys against a list of known hosts, similar to OpenSSH's approach.\n- **Do not** disable host key checking in your production code. While it might seem convenient for development or testing environments, it significantly increases the risk of security breaches.\n\n## References\n\n- [GoDoc for x/crypto/ssh](https://pkg.go.dev/golang.org/x/crypto/ssh)\n- [Secure use of SSH - OpenSSH](https://www.openssh.com/)"}},{"id":"go_gosec_crypto_weak_tls_version","name":"go_gosec_crypto_weak_tls_version","shortDescription":{"text":"Usage of deprecated TLS version"},"fullDescription":{"text":"Usage of deprecated TLS version"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nTLS (Transport Layer Security) versions 1.0 and 1.1 have known vulnerabilities and using them introduces security risks to your application. These outdated TLS versions can lead to the interception and compromise of sensitive data during transmission.\n\n## Remediations\n\n- **Do** enforce the use of TLS 1.3 when configuring Go's TLS library. TLS 1.3 offers significant security improvements, helping to protect data from known vulnerabilities present in older versions.\n  ```go\n    cfg := \u0026tls.Config{\n      MinVersion:   tls.VersionTLS13,\n      ...\n    }\n  ```\n- **Do** utilize configurations that support Perfect Forward Secrecy (PFS) with TLS 1.3. PFS enhances security by ensuring that past communications remain secure even if future session keys are compromised.\n- **Do** regularly update your Go version and dependencies to incorporate the latest security fixes and improvements.\n- **Do not** configure your server to accept TLS versions 1.0 or 1.1. Removing these options from your TLS configuration is crucial to prevent downgrade attacks.\n\n## References\n\n- [IETF's Deprecation of TLS 1.0 and 1.1](https://tools.ietf.org/html/rfc8996)\n- [OWASP TLS Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)\n- [Go `crypto/tls` package documentation](https://pkg.go.dev/crypto/tls)","markdown":"## Description\n\nTLS (Transport Layer Security) versions 1.0 and 1.1 have known vulnerabilities and using them introduces security risks to your application. These outdated TLS versions can lead to the interception and compromise of sensitive data during transmission.\n\n## Remediations\n\n- **Do** enforce the use of TLS 1.3 when configuring Go's TLS library. TLS 1.3 offers significant security improvements, helping to protect data from known vulnerabilities present in older versions.\n  ```go\n    cfg := \u0026tls.Config{\n      MinVersion:   tls.VersionTLS13,\n      ...\n    }\n  ```\n- **Do** utilize configurations that support Perfect Forward Secrecy (PFS) with TLS 1.3. PFS enhances security by ensuring that past communications remain secure even if future session keys are compromised.\n- **Do** regularly update your Go version and dependencies to incorporate the latest security fixes and improvements.\n- **Do not** configure your server to accept TLS versions 1.0 or 1.1. Removing these options from your TLS configuration is crucial to prevent downgrade attacks.\n\n## References\n\n- [IETF's Deprecation of TLS 1.0 and 1.1](https://tools.ietf.org/html/rfc8996)\n- [OWASP TLS Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html)\n- [Go `crypto/tls` package documentation](https://pkg.go.dev/crypto/tls)"}},{"id":"go_third_parties_open_telemetry","name":"go_third_parties_open_telemetry","shortDescription":{"text":"Leakage of sensitive data to OpenTelemetry"},"fullDescription":{"text":"Leakage of sensitive data to OpenTelemetry"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeaking sensitive data to third parties like OpenTelemetry is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third parties like OpenTelemetry.\n\n## References\n- [OpenTelemetry Docs](https://opentelemetry.io/docs/)\n","markdown":"## Description\n\nLeaking sensitive data to third parties like OpenTelemetry is a common cause of data leaks and can lead to data breaches.\n\n## Remediations\n\n- **Do** ensure all sensitive data is removed when sending data to third parties like OpenTelemetry.\n\n## References\n- [OpenTelemetry Docs](https://opentelemetry.io/docs/)\n"}},{"id":"go_gosec_blocklist_des","name":"go_gosec_blocklist_des","shortDescription":{"text":"Import of weak encryption algorithm (DES)"},"fullDescription":{"text":"Import of weak encryption algorithm (DES)"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nThe Data Encryption Standard (DES) is an outdated encryption algorithm that is officially considered insecure and is no longer recommended for use. DES was withdrawn as a standard by the National Institute of Standards and Technology (NIST) in 2005 because of its 56-bit key size which makes it susceptible to brute-force attacks.\n\n## Remediations\n\n- **Do not** use DES for encrypting data. Its known vulnerabilities and insecurities make it an unsuitable choice for protecting sensitive information.\n- **Do** implement the Advanced Encryption Standard (AES) with a key size of 256 bits (AES-256) for encryption. AES-256 is recognized for its strong security properties and is widely accepted as a secure replacement for DES.\n\n## References\n\n- [NIST Recommendations](https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final)\n- [AES-256 Encryption](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard)","markdown":"## Description\n\nThe Data Encryption Standard (DES) is an outdated encryption algorithm that is officially considered insecure and is no longer recommended for use. DES was withdrawn as a standard by the National Institute of Standards and Technology (NIST) in 2005 because of its 56-bit key size which makes it susceptible to brute-force attacks.\n\n## Remediations\n\n- **Do not** use DES for encrypting data. Its known vulnerabilities and insecurities make it an unsuitable choice for protecting sensitive information.\n- **Do** implement the Advanced Encryption Standard (AES) with a key size of 256 bits (AES-256) for encryption. AES-256 is recognized for its strong security properties and is widely accepted as a secure replacement for DES.\n\n## References\n\n- [NIST Recommendations](https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final)\n- [AES-256 Encryption](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard)"}},{"id":"go_lang_insufficiently_random_values","name":"go_lang_insufficiently_random_values","shortDescription":{"text":"Usage of insufficient random value"},"fullDescription":{"text":"Usage of insufficient random value"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nYour application is at risk when it uses predictable random values, particularly for security-related functions.\n\n## Remediations\n\n- **Do** use a stronger, more secure library for generating random values. This is crucial for enhancing the security of your application.\n  ```go\n  import (\n    \"crypto/rand\"\n    \"encoding/base64\"\n    \"fmt\"\n  )\n\n  func generateSecureToken(length int) (string, error) {\n    bytes := make([]byte, length)\n    _, err := rand.Read(bytes)\n    if err != nil {\n      return \"\", err\n    }\n\n    // Encode the binary data to a string for easier use\n    return base64.URLEncoding.EncodeToString(bytes), nil\n  }\n  ```\n\n## References\n\n- [Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html)","markdown":"## Description\n\nYour application is at risk when it uses predictable random values, particularly for security-related functions.\n\n## Remediations\n\n- **Do** use a stronger, more secure library for generating random values. This is crucial for enhancing the security of your application.\n  ```go\n  import (\n    \"crypto/rand\"\n    \"encoding/base64\"\n    \"fmt\"\n  )\n\n  func generateSecureToken(length int) (string, error) {\n    bytes := make([]byte, length)\n    _, err := rand.Read(bytes)\n    if err != nil {\n      return \"\", err\n    }\n\n    // Encode the binary data to a string for easier use\n    return base64.URLEncoding.EncodeToString(bytes), nil\n  }\n  ```\n\n## References\n\n- [Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html)"}},{"id":"go_gosec_crypto_weak_key_strength","name":"go_gosec_crypto_weak_key_strength","shortDescription":{"text":"Usage of inadequate encryption strength"},"fullDescription":{"text":"Usage of inadequate encryption strength"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nYour application uses RSA encryption with a key length shorter than the recommended 2048 bits. Keys under 2048 bits are vulnerable because of the increasing power of modern computers, which could break the encryption by factoring the key.\n\n## Remediations\n\n- **Do** generate RSA keys with a minimum of 2048 bits. This meets NIST recommendations and protects against the risk of keys being compromised by advancements in computing power. Keys shorter than 2048 bits do not provide adequate protection against brute-force attacks.\n  ```go\n    privateKey, err := rsa.GenerateKey(rand.Reader, 2048)\n  ```\n- **Do** adhere to industry standards and guidelines for cryptographic practices to ensure the security of your data.\n\n## References\n\n- [NIST Special Publication 800-57 Part 1](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final)","markdown":"## Description\n\nYour application uses RSA encryption with a key length shorter than the recommended 2048 bits. Keys under 2048 bits are vulnerable because of the increasing power of modern computers, which could break the encryption by factoring the key.\n\n## Remediations\n\n- **Do** generate RSA keys with a minimum of 2048 bits. This meets NIST recommendations and protects against the risk of keys being compromised by advancements in computing power. Keys shorter than 2048 bits do not provide adequate protection against brute-force attacks.\n  ```go\n    privateKey, err := rsa.GenerateKey(rand.Reader, 2048)\n  ```\n- **Do** adhere to industry standards and guidelines for cryptographic practices to ensure the security of your data.\n\n## References\n\n- [NIST Special Publication 800-57 Part 1](https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final)"}},{"id":"go_gosec_memory_math_big_rat","name":"go_gosec_memory_math_big_rat","shortDescription":{"text":"Possible integer overflow when converting strings"},"fullDescription":{"text":"Possible integer overflow when converting strings"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nWhen you convert strings to integers in Go using `strconv.Atoi`, you might encounter an integer overflow if you assign the result to a smaller integer type like `int16` or `int32`. This is because the size of `int` type in Go is not fixed and depends on the system architecture (32 bits on a 32-bit system and 64 bits on a 64-bit system). An overflow occurs if the `strconv.Atoi` return value is too large for the intended smaller integer type.\n\n## Remediations\n\n- **Do** verify the value from `strconv.Atoi` fits within the range of your target integer type before conversion.\n  ```go\n  if intValue, err := strconv.Atoi(stringValue); err == nil {\n    if intValue \u003e= math.MinInt16 \u0026\u0026 intValue \u003c= math.MaxInt16 {\n      int16Value := int16(intValue)\n    }\n  }\n  ```\n- **Do** use type-specific parsing functions like `strconv.ParseInt` with the appropriate bit size to ensure you get the type you need.\n  ```go\n  if int64Value, err := strconv.ParseInt(stringValue, 10, 16); err == nil {\n    int16Value := int16(int64Value)\n  }\n  ```\n- **Do not** cast the result of `strconv.Atoi` to a smaller integer type without ensuring the value is within the acceptable range for that type.\n- **Do not** ignore errors from `strconv.Atoi`. Always handle them to detect conversion problems, including possible overflows.\n\n## References\n\n- [Go strconv package](https://pkg.go.dev/strconv)\n- [Go math package for min/max constants](https://pkg.go.dev/math#pkg-constants)","markdown":"## Description\n\nWhen you convert strings to integers in Go using `strconv.Atoi`, you might encounter an integer overflow if you assign the result to a smaller integer type like `int16` or `int32`. This is because the size of `int` type in Go is not fixed and depends on the system architecture (32 bits on a 32-bit system and 64 bits on a 64-bit system). An overflow occurs if the `strconv.Atoi` return value is too large for the intended smaller integer type.\n\n## Remediations\n\n- **Do** verify the value from `strconv.Atoi` fits within the range of your target integer type before conversion.\n  ```go\n  if intValue, err := strconv.Atoi(stringValue); err == nil {\n    if intValue \u003e= math.MinInt16 \u0026\u0026 intValue \u003c= math.MaxInt16 {\n      int16Value := int16(intValue)\n    }\n  }\n  ```\n- **Do** use type-specific parsing functions like `strconv.ParseInt` with the appropriate bit size to ensure you get the type you need.\n  ```go\n  if int64Value, err := strconv.ParseInt(stringValue, 10, 16); err == nil {\n    int16Value := int16(int64Value)\n  }\n  ```\n- **Do not** cast the result of `strconv.Atoi` to a smaller integer type without ensuring the value is within the acceptable range for that type.\n- **Do not** ignore errors from `strconv.Atoi`. Always handle them to detect conversion problems, including possible overflows.\n\n## References\n\n- [Go strconv package](https://pkg.go.dev/strconv)\n- [Go math package for min/max constants](https://pkg.go.dev/math#pkg-constants)"}},{"id":"go_gosec_blocklist_rc4","name":"go_gosec_blocklist_rc4","shortDescription":{"text":"Import of weak encryption algorithm (RCA)"},"fullDescription":{"text":"Import of weak encryption algorithm (RCA)"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nThe RC4 encryption algorithm is outdated and vulnerable. It has been found to have significant security flaws, including predictable key generation and weak randomization, which have been exploited in various attacks. These vulnerabilities make RC4 unsuitable for secure data encryption.\n\n## Remediations\n\n- **Do not** use RC4 for encrypting data. Its vulnerabilities to cryptanalysis and practical attacks compromise data security.\n- **Do** switch to AES-256 for encryption. AES-256 is a secure and widely accepted standard that provides strong protection against attacks. Using AES-256 ensures compliance with current security standards and provides a robust defense against known cryptographic attacks.\n\n## References\n\n- [NIST Guidelines on Cryptography](https://csrc.nist.gov/publications/detail/sp/800-38a/final)","markdown":"## Description\n\nThe RC4 encryption algorithm is outdated and vulnerable. It has been found to have significant security flaws, including predictable key generation and weak randomization, which have been exploited in various attacks. These vulnerabilities make RC4 unsuitable for secure data encryption.\n\n## Remediations\n\n- **Do not** use RC4 for encrypting data. Its vulnerabilities to cryptanalysis and practical attacks compromise data security.\n- **Do** switch to AES-256 for encryption. AES-256 is a secure and widely accepted standard that provides strong protection against attacks. Using AES-256 ensures compliance with current security standards and provides a robust defense against known cryptographic attacks.\n\n## References\n\n- [NIST Guidelines on Cryptography](https://csrc.nist.gov/publications/detail/sp/800-38a/final)"}},{"id":"go_gosec_file_permissions_file_perm","name":"go_gosec_file_permissions_file_perm","shortDescription":{"text":"Permissive file assignment"},"fullDescription":{"text":"Permissive file assignment"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nSetting overly permissive file permissions exposes your system to risks such as unauthorized access, data tampering, and potential system compromise. This vulnerability arises when files are created or updated without adequately restrictive permissions, allowing unauthorized users to read, modify, or execute files.\n\n## Remediations\n\n- **Do not** use overly permissive file permissions, such as `0777`, which grants read, write, and execute permissions to all users.\n- **Do** set file permissions to restrict access appropriately:\n  - `0400` for read-only access by the file's owner.\n  - `0200` for write-only access by the file's owner.\n  - `0600` for read and write access by the file's owner, suitable for files that the application needs to read from and write to.\n- **Do** use Go's `os` package to manage file permissions effectively. For example, use `os.OpenFile` with appropriate permission flags such as 0600.\n  ```go\n    f, err := os.OpenFile(\"file.txt\", os.O_CREATE|os.O_WRONLY, 0600)\n    ...\n  ```\n- **Do** verify file permissions after creation or update to ensure they are set as intended.\n- **Do** consider setting umask to a secure default, if your application creates multiple files, to ensure that files are created with safe default permissions.\n- **Do** regularly review and audit file permissions in your system to ensure they adhere to the principle of least privilege, minimizing the access level to what is strictly necessary for operational functionality.","markdown":"## Description\n\nSetting overly permissive file permissions exposes your system to risks such as unauthorized access, data tampering, and potential system compromise. This vulnerability arises when files are created or updated without adequately restrictive permissions, allowing unauthorized users to read, modify, or execute files.\n\n## Remediations\n\n- **Do not** use overly permissive file permissions, such as `0777`, which grants read, write, and execute permissions to all users.\n- **Do** set file permissions to restrict access appropriately:\n  - `0400` for read-only access by the file's owner.\n  - `0200` for write-only access by the file's owner.\n  - `0600` for read and write access by the file's owner, suitable for files that the application needs to read from and write to.\n- **Do** use Go's `os` package to manage file permissions effectively. For example, use `os.OpenFile` with appropriate permission flags such as 0600.\n  ```go\n    f, err := os.OpenFile(\"file.txt\", os.O_CREATE|os.O_WRONLY, 0600)\n    ...\n  ```\n- **Do** verify file permissions after creation or update to ensure they are set as intended.\n- **Do** consider setting umask to a secure default, if your application creates multiple files, to ensure that files are created with safe default permissions.\n- **Do** regularly review and audit file permissions in your system to ensure they adhere to the principle of least privilege, minimizing the access level to what is strictly necessary for operational functionality."}},{"id":"go_gosec_leak_pprof_endpoint","name":"go_gosec_leak_pprof_endpoint","shortDescription":{"text":"Usage of active debug code (pprof enabled)"},"fullDescription":{"text":"Usage of active debug code (pprof enabled)"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nEnabling Go's `net/http/pprof` in production environments exposes runtime profiling data via a `/debug/pprof` endpoint, creating a security vulnerability. This tool is part of Go's standard library and, while useful for debugging, it does not have authentication controls. This can lead to sensitive information leaks about the application's runtime state and environment if left accessible in production.\n\n## Remediations\n\n- **Do not** include `net/http/pprof` in your production code. Remove any imports of this package before deploying to ensure the profiling endpoint is not exposed.\n- **Do** use build tags for conditional compilation, and only allow profiling in non-production builds.\n- **Do** configure environment-specific settings to enable or disable profiling endpoints based on the deployment environment.\n- **Do** implement strong authentication mechanisms if profiling must be enabled in a controlled production scenario to secure the endpoint.\n\n## References\n\n- [Go net/http/pprof Package Documentation](https://pkg.go.dev/net/http/pprof)\n- [Go Build Constraints Documentation](https://pkg.go.dev/go/build#hdr-Build_Constraints)\n- [OWASP Secure Product Design Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html)","markdown":"## Description\n\nEnabling Go's `net/http/pprof` in production environments exposes runtime profiling data via a `/debug/pprof` endpoint, creating a security vulnerability. This tool is part of Go's standard library and, while useful for debugging, it does not have authentication controls. This can lead to sensitive information leaks about the application's runtime state and environment if left accessible in production.\n\n## Remediations\n\n- **Do not** include `net/http/pprof` in your production code. Remove any imports of this package before deploying to ensure the profiling endpoint is not exposed.\n- **Do** use build tags for conditional compilation, and only allow profiling in non-production builds.\n- **Do** configure environment-specific settings to enable or disable profiling endpoints based on the deployment environment.\n- **Do** implement strong authentication mechanisms if profiling must be enabled in a controlled production scenario to secure the endpoint.\n\n## References\n\n- [Go net/http/pprof Package Documentation](https://pkg.go.dev/net/http/pprof)\n- [Go Build Constraints Documentation](https://pkg.go.dev/go/build#hdr-Build_Constraints)\n- [OWASP Secure Product Design Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html)"}},{"id":"go_lang_permissive_regex_validation","name":"go_lang_permissive_regex_validation","shortDescription":{"text":"Permissive regular expression used in matching"},"fullDescription":{"text":"Permissive regular expression used in matching"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nWhen matching with regular expressions -- especially for validation purposes -- it is crucial to specify the start and end of the text boundaries. This ensures the entire text is validated, not just parts of it, and prevents attackers from bypassing validation with partially matching input. Use \\A and \\z (or \\Z) over ^ and $ to specify text boundaries, because these accurately mark the beginning and end of the text, even in multiline mode.\n\n## Remediations\n\n- **Do not** use regular expressions for validation without specifying start and end boundaries. This can lead to partial matches being considered valid, when they may contain unsafe input.\n  ```go\n  regexp.MustCompile(\"foo\") // unsafe\n  ```\n- **Do not** use line-based boundaries (^ and $) for validation as they may not secure the entire text.\n  ```go\n  regexp.MustCompile(\"^foo$\") // unsafe\n  ```\n- **Do** use whole-text boundaries (\\A and \\z or \\Z) in your regular expressions to ensure comprehensive validation.\n  ```go\n  regexp.MustCompile(\"\\Afoo\\z\")\n  ```","markdown":"## Description\n\nWhen matching with regular expressions -- especially for validation purposes -- it is crucial to specify the start and end of the text boundaries. This ensures the entire text is validated, not just parts of it, and prevents attackers from bypassing validation with partially matching input. Use \\A and \\z (or \\Z) over ^ and $ to specify text boundaries, because these accurately mark the beginning and end of the text, even in multiline mode.\n\n## Remediations\n\n- **Do not** use regular expressions for validation without specifying start and end boundaries. This can lead to partial matches being considered valid, when they may contain unsafe input.\n  ```go\n  regexp.MustCompile(\"foo\") // unsafe\n  ```\n- **Do not** use line-based boundaries (^ and $) for validation as they may not secure the entire text.\n  ```go\n  regexp.MustCompile(\"^foo$\") // unsafe\n  ```\n- **Do** use whole-text boundaries (\\A and \\z or \\Z) in your regular expressions to ensure comprehensive validation.\n  ```go\n  regexp.MustCompile(\"\\Afoo\\z\")\n  ```"}},{"id":"go_gosec_blocklist_cgi","name":"go_gosec_blocklist_cgi","shortDescription":{"text":"Usage of vulnerable CGI package"},"fullDescription":{"text":"Usage of vulnerable CGI package"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nThe `net/http/cgi` package in Go versions before 1.6.3 is vulnerable to the Httpoxy attack. This vulnerability, identified as CVE-2016-5386, occurs because of how CGI and FastCGI protocols manage certain environment variables. Attackers can exploit this to intercept and redirect outgoing HTTP requests from the web application.\n\n## Remediations\n\n- **Do** update your Go version to 1.6.3 or later to mitigate this vulnerability.\n- **Do** opt for alternative packages, like the standard `net/http` library, for handling HTTP requests that do not use the CGI protocol.\n- **Do not** use the `net/http/cgi` package if your Go version is older than 1.6.3, as it is vulnerable to the Httpoxy attack.\n  ```go\n  import \"net/http/cgi\"\n  ```\n- **Do** ensure that environment variables like `HTTP_PROXY` are not unintentionally exposed, as this can be leveraged for Httpoxy attacks.\n\n## References\n\n- [Httpoxy.org](https://httpoxy.org/)","markdown":"## Description\n\nThe `net/http/cgi` package in Go versions before 1.6.3 is vulnerable to the Httpoxy attack. This vulnerability, identified as CVE-2016-5386, occurs because of how CGI and FastCGI protocols manage certain environment variables. Attackers can exploit this to intercept and redirect outgoing HTTP requests from the web application.\n\n## Remediations\n\n- **Do** update your Go version to 1.6.3 or later to mitigate this vulnerability.\n- **Do** opt for alternative packages, like the standard `net/http` library, for handling HTTP requests that do not use the CGI protocol.\n- **Do not** use the `net/http/cgi` package if your Go version is older than 1.6.3, as it is vulnerable to the Httpoxy attack.\n  ```go\n  import \"net/http/cgi\"\n  ```\n- **Do** ensure that environment variables like `HTTP_PROXY` are not unintentionally exposed, as this can be leveraged for Httpoxy attacks.\n\n## References\n\n- [Httpoxy.org](https://httpoxy.org/)"}},{"id":"go_gosec_filesystem_ziparchive","name":"go_gosec_filesystem_ziparchive","shortDescription":{"text":"Missing protection against 'Zip Slip' path traversal"},"fullDescription":{"text":"Missing protection against 'Zip Slip' path traversal"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nYour application is vulnerable to a 'Zip Slip' path traversal attack when it extracts files from archives that are not trusted. This occurs because malicious archives may contain files with relative paths aiming to escape the intended directory. As a result, these files could overwrite important system files or be placed in sensitive locations, leading to security breaches.\n\n## Remediations\n\n- **Do** implement checks to limit the zip archive's size. This prevents 'Zip Bombs', which are archives that decompress into sizes much larger than expected. For example, use `file.UncompressedSize64` to check the size of a file within a ZIP file.\n- **Do** generate unique filenames for extracted files or sanitize the original filenames to avoid overwriting files intentionally. You can use `filepath.Base`, for example, to extract the filename from a path and discard any directory information.\n  ```go\n  name := filepath.Base(file.Name)\n  ```\n- **Do** validate the paths of extracted files to ensure they are written to a specified, trusted directory without traversing outside of it.\n- **Do** process only regular files. Exclude symbolic links to prevent indirect file read/write vulnerabilities.\n  ```go\n  if !file.Mode().IsRegular() {\n    log.Fatal(\"non-regular file: %s\\n\", file.Name)\n  }\n  ```\n- **Do** ensure directories within the zip archive are processed securely by cleaning the path and strictly validating it against the base path.\n\n## References\n\n- [Go Documentation: archive/zip package](https://pkg.go.dev/archive/zip)","markdown":"## Description\n\nYour application is vulnerable to a 'Zip Slip' path traversal attack when it extracts files from archives that are not trusted. This occurs because malicious archives may contain files with relative paths aiming to escape the intended directory. As a result, these files could overwrite important system files or be placed in sensitive locations, leading to security breaches.\n\n## Remediations\n\n- **Do** implement checks to limit the zip archive's size. This prevents 'Zip Bombs', which are archives that decompress into sizes much larger than expected. For example, use `file.UncompressedSize64` to check the size of a file within a ZIP file.\n- **Do** generate unique filenames for extracted files or sanitize the original filenames to avoid overwriting files intentionally. You can use `filepath.Base`, for example, to extract the filename from a path and discard any directory information.\n  ```go\n  name := filepath.Base(file.Name)\n  ```\n- **Do** validate the paths of extracted files to ensure they are written to a specified, trusted directory without traversing outside of it.\n- **Do** process only regular files. Exclude symbolic links to prevent indirect file read/write vulnerabilities.\n  ```go\n  if !file.Mode().IsRegular() {\n    log.Fatal(\"non-regular file: %s\\n\", file.Name)\n  }\n  ```\n- **Do** ensure directories within the zip archive are processed securely by cleaning the path and strictly validating it against the base path.\n\n## References\n\n- [Go Documentation: archive/zip package](https://pkg.go.dev/archive/zip)"}},{"id":"go_lang_information_leakage","name":"go_lang_information_leakage","shortDescription":{"text":"Leakage of sensitive information in exception message"},"fullDescription":{"text":"Leakage of sensitive information in exception message"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nLeakage of sensitive information in exception messages can compromise your application's security. This occurs when exception messages reveal too much about your application's internal workings or user-specific data, potentially aiding attackers in crafting targeted attacks such as path traversal.\n\n## Remediations\n\n- **Do not** include sensitive information in exception messages. This prevents accidental exposure of application details or user data.\n- **Do** limit the information logged in error messages to only what is necessary for troubleshooting. This minimizes the risk of information leakage.\n\n## References\n\n- [Web Application Security Consortium: Information Leakage](http://projects.webappsec.org/w/page/13246936/Information%20Leakage)","markdown":"## Description\n\nLeakage of sensitive information in exception messages can compromise your application's security. This occurs when exception messages reveal too much about your application's internal workings or user-specific data, potentially aiding attackers in crafting targeted attacks such as path traversal.\n\n## Remediations\n\n- **Do not** include sensitive information in exception messages. This prevents accidental exposure of application details or user data.\n- **Do** limit the information logged in error messages to only what is necessary for troubleshooting. This minimizes the risk of information leakage.\n\n## References\n\n- [Web Application Security Consortium: Information Leakage](http://projects.webappsec.org/w/page/13246936/Information%20Leakage)"}},{"id":"go_gosec_secrets_secrets","name":"go_gosec_secrets_secrets","shortDescription":{"text":"Usage of hard-coded secret"},"fullDescription":{"text":"Usage of hard-coded secret"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nStoring secrets like keys, passwords, or API tokens in your source code introduces a significant security risk. If your code is exposed or accessed improperly, these secrets can be easily obtained by attackers.\n\n## Remediations\n\n- **Do** implement dynamic secret retrieval. Fetch secrets at runtime from a secure source instead of embedding them in your source files.\n- **Do** use environment variables to provide secrets to your application at runtime, keeping them out of your source code.\n- **Do** utilize secrets management systems. These tools securely store and handle sensitive information away from your codebase.\n- **Do** store secrets in encrypted configuration files. Decrypt these secrets only within the application at runtime.\n- **Do** ensure strict access control for the storage locations of your secrets to prevent unauthorized access.\n- **Do** regularly audit and rotate secrets to reduce risks in case they are compromised.\n\n## References\n\n- [OWASP: Use of Hard-coded Passwords](https://owasp.org/www-community/vulnerabilities/Use_of_hard-coded_password)\n- [OWASP: Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html#21-high-availability)","markdown":"## Description\n\nStoring secrets like keys, passwords, or API tokens in your source code introduces a significant security risk. If your code is exposed or accessed improperly, these secrets can be easily obtained by attackers.\n\n## Remediations\n\n- **Do** implement dynamic secret retrieval. Fetch secrets at runtime from a secure source instead of embedding them in your source files.\n- **Do** use environment variables to provide secrets to your application at runtime, keeping them out of your source code.\n- **Do** utilize secrets management systems. These tools securely store and handle sensitive information away from your codebase.\n- **Do** store secrets in encrypted configuration files. Decrypt these secrets only within the application at runtime.\n- **Do** ensure strict access control for the storage locations of your secrets to prevent unauthorized access.\n- **Do** regularly audit and rotate secrets to reduce risks in case they are compromised.\n\n## References\n\n- [OWASP: Use of Hard-coded Passwords](https://owasp.org/www-community/vulnerabilities/Use_of_hard-coded_password)\n- [OWASP: Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html#21-high-availability)"}},{"id":"go_gosec_injection_ssrf_injection","name":"go_gosec_injection_ssrf_injection","shortDescription":{"text":"Unsanitized user input in HTTP request (SSRF)"},"fullDescription":{"text":"Unsanitized user input in HTTP request (SSRF)"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nIncluding unsanitized user input in HTTP requests puts your application at risk of Server-Side Request Forgery (SSRF). This is a security vulnerability that occurs when a server-side application makes HTTP requests to arbitrary URLs controlled by the user. SSRF can be exploited by attackers to target internal systems behind firewalls that are otherwise inaccessible from the external network, by tricking the server into making requests to these systems.\n\n## Remediations\n\n- **Do not** use direct user input to construct URLs for backend requests. If user input is necessary, ensure it is strictly validated or sanitized to prevent malicious manipulation.\n- **Do** use a safelist or predefined mapping when incorporating user input in URLs. This ensures that your application only redirects users to safe and intended destinations.\n  ```go\n  safeURLs := map[string]string{\n      \"key1\": \"https://safe-domain1.com\",\n      \"key2\": \"https://safe-domain2.com\",\n  }\n  requestedKey := getUserInput()\n  if url, ok := safeURLs[requestedKey]; ok {\n      // continue with request\n  } else {\n      log.Fatal(\"Requested URL is not allowed\")\n  }\n  ```\n- **Do** implement IP safelists and blocklists to customize and block specific IP ranges, especially those that are private, loopback, or otherwise non-routable.\n- **Do** use network-level security measures. If your HTTP client does not support IP range blocking, run it with restricted system permissions or within a network environment where firewall rules can effectively block requests to dangerous addresses.\n- **Do** consider using a secure HTTP proxy to route all backend HTTP requests. This proxy can serve as a filter to block requests to potentially harmful addresses, acting as an additional layer of security.\n\n## References\n\n- [OWASP SSRF Prevention Cheat Sheet](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery)","markdown":"## Description\n\nIncluding unsanitized user input in HTTP requests puts your application at risk of Server-Side Request Forgery (SSRF). This is a security vulnerability that occurs when a server-side application makes HTTP requests to arbitrary URLs controlled by the user. SSRF can be exploited by attackers to target internal systems behind firewalls that are otherwise inaccessible from the external network, by tricking the server into making requests to these systems.\n\n## Remediations\n\n- **Do not** use direct user input to construct URLs for backend requests. If user input is necessary, ensure it is strictly validated or sanitized to prevent malicious manipulation.\n- **Do** use a safelist or predefined mapping when incorporating user input in URLs. This ensures that your application only redirects users to safe and intended destinations.\n  ```go\n  safeURLs := map[string]string{\n      \"key1\": \"https://safe-domain1.com\",\n      \"key2\": \"https://safe-domain2.com\",\n  }\n  requestedKey := getUserInput()\n  if url, ok := safeURLs[requestedKey]; ok {\n      // continue with request\n  } else {\n      log.Fatal(\"Requested URL is not allowed\")\n  }\n  ```\n- **Do** implement IP safelists and blocklists to customize and block specific IP ranges, especially those that are private, loopback, or otherwise non-routable.\n- **Do** use network-level security measures. If your HTTP client does not support IP range blocking, run it with restricted system permissions or within a network environment where firewall rules can effectively block requests to dangerous addresses.\n- **Do** consider using a secure HTTP proxy to route all backend HTTP requests. This proxy can serve as a filter to block requests to potentially harmful addresses, acting as an additional layer of security.\n\n## References\n\n- [OWASP SSRF Prevention Cheat Sheet](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery)"}},{"id":"go_gosec_filesystem_poor_write_permissions","name":"go_gosec_filesystem_poor_write_permissions","shortDescription":{"text":"Permissive file creation"},"fullDescription":{"text":"Permissive file creation"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nYour application sets file permissions that are overly permissive. This oversight could let unauthorized individuals read, write, or execute files, which could lead to the exposure of sensitive information or other security risks.\n\n## Remediations\n\n- **Do** use restrictive file permissions. Assign file permissions that strictly limit access, aligning with what your application genuinely needs:\n  - `0400` for read-only access by the file's owner.\n  - `0200` for write-only access by the file's owner.\n  - `0600` for read and write access by the file's owner, suitable for files that the application needs to read from and write to.\n- **Do** set the correct permissions when you create or modify files. This step is crucial to prevent unauthorized access right from the start.\n- **Do** regularly review and audit file permissions in your system to ensure they adhere to the principle of least privilege, minimizing the access level to what is strictly necessary for operational functionality.\n\n## References\n\n- [Go Documentation for os Package](https://pkg.go.dev/os)\n- [Linux 'chmod' Command](https://linux.die.net/man/1/chmod)\n- [OWASP File Handling Best Practices](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html)","markdown":"## Description\n\nYour application sets file permissions that are overly permissive. This oversight could let unauthorized individuals read, write, or execute files, which could lead to the exposure of sensitive information or other security risks.\n\n## Remediations\n\n- **Do** use restrictive file permissions. Assign file permissions that strictly limit access, aligning with what your application genuinely needs:\n  - `0400` for read-only access by the file's owner.\n  - `0200` for write-only access by the file's owner.\n  - `0600` for read and write access by the file's owner, suitable for files that the application needs to read from and write to.\n- **Do** set the correct permissions when you create or modify files. This step is crucial to prevent unauthorized access right from the start.\n- **Do** regularly review and audit file permissions in your system to ensure they adhere to the principle of least privilege, minimizing the access level to what is strictly necessary for operational functionality.\n\n## References\n\n- [Go Documentation for os Package](https://pkg.go.dev/os)\n- [Linux 'chmod' Command](https://linux.die.net/man/1/chmod)\n- [OWASP File Handling Best Practices](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html)"}},{"id":"go_lang_weak_password_encryption_sha1","name":"go_lang_weak_password_encryption_sha1","shortDescription":{"text":"Usage of weak hashing library on a password (SHA-1)"},"fullDescription":{"text":"Usage of weak hashing library on a password (SHA-1)"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nUsing a weak hashing library like SHA-1 for passwords increases the risk of data breaches. SHA-1 is vulnerable to collision attacks, where two different inputs can produce the same hash value, compromising data integrity and security.\n\n## Remediations\n\n- **Do not** use SHA-1 for hashing passwords. This algorithm is no longer considered secure and can make your system vulnerable.\n  ```go\n  sha1.Sum([]byte('password')) // unsafe\n  ```\n- **Do** opt for stronger hashing algorithms such as SHA-256 to enhance security.\n  ```go\n  sha256.Sum256([]byte('string'))\n  ```","markdown":"## Description\n\nUsing a weak hashing library like SHA-1 for passwords increases the risk of data breaches. SHA-1 is vulnerable to collision attacks, where two different inputs can produce the same hash value, compromising data integrity and security.\n\n## Remediations\n\n- **Do not** use SHA-1 for hashing passwords. This algorithm is no longer considered secure and can make your system vulnerable.\n  ```go\n  sha1.Sum([]byte('password')) // unsafe\n  ```\n- **Do** opt for stronger hashing algorithms such as SHA-256 to enhance security.\n  ```go\n  sha256.Sum256([]byte('string'))\n  ```"}},{"id":"go_gosec_subproc_subproc","name":"go_gosec_subproc_subproc","shortDescription":{"text":"Unsanitized external input in code execution"},"fullDescription":{"text":"Unsanitized external input in code execution"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nUnsanitized external input in code execution can result in code injection. This vulnerability arises when external or user-provided data is directly used in the execution flow of a program without proper sanitization, potentially leading to unauthorized actions or access.\n\n## Remediations\n\n- **Do not** pass unsanitized external input directly to execution functions. This practice can introduce code injection vulnerabilities.\n- **Do** implement thorough input validation. Ensure all external input is checked against a strict set of rules to verify it does not contain harmful characters or patterns.\n\n## References\n\n- [OWASP Code injection explained](https://owasp.org/www-community/attacks/Code_Injection)","markdown":"## Description\n\nUnsanitized external input in code execution can result in code injection. This vulnerability arises when external or user-provided data is directly used in the execution flow of a program without proper sanitization, potentially leading to unauthorized actions or access.\n\n## Remediations\n\n- **Do not** pass unsanitized external input directly to execution functions. This practice can introduce code injection vulnerabilities.\n- **Do** implement thorough input validation. Ensure all external input is checked against a strict set of rules to verify it does not contain harmful characters or patterns.\n\n## References\n\n- [OWASP Code injection explained](https://owasp.org/www-community/attacks/Code_Injection)"}},{"id":"go_gosec_memory_memory_aliasing","name":"go_gosec_memory_memory_aliasing","shortDescription":{"text":"Usage of single iteration variable in range loop"},"fullDescription":{"text":"Usage of single iteration variable in range loop"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nIn Go, using the `for ... range` loop with a single iteration variable can lead to errors. This happens because the loop uses the same memory address for the iteration variable throughout its execution. When you store or use the address of this variable across different iterations, it can overwrite values unexpectedly. This issue is especially problematic in concurrent operations or when deferring functions inside the loop.\n\n## Remediations\n\n- **Do** create a new variable inside the loop to ensure each iteration uses a unique memory address.\n  ```go\n  for _, n := range []someStruct{{1}, {2}, {3}, {4}} {\n    localVar := n\n    // use localVar instead of n\n  }\n  ```\n- **Do** use indexed addressing to directly reference the elements in an array or slice, avoiding the shared address problem.\n  ```go\n  for i := range mySlice {\n    // use \u0026mySlice[i] for a stable address\n  }\n  ```\n- **Do not** store the address of the iteration variable. This practice leads to all references pointing to the same location in memory, causing errors.\n- **Do not** use the iteration variable's address in goroutines. This can result in race conditions or logical errors if the variable's value changing before the goroutine accesses it.\n\n## References\n\n- [Go For Statements](https://go.dev/ref/spec#For_statements)","markdown":"## Description\n\nIn Go, using the `for ... range` loop with a single iteration variable can lead to errors. This happens because the loop uses the same memory address for the iteration variable throughout its execution. When you store or use the address of this variable across different iterations, it can overwrite values unexpectedly. This issue is especially problematic in concurrent operations or when deferring functions inside the loop.\n\n## Remediations\n\n- **Do** create a new variable inside the loop to ensure each iteration uses a unique memory address.\n  ```go\n  for _, n := range []someStruct{{1}, {2}, {3}, {4}} {\n    localVar := n\n    // use localVar instead of n\n  }\n  ```\n- **Do** use indexed addressing to directly reference the elements in an array or slice, avoiding the shared address problem.\n  ```go\n  for i := range mySlice {\n    // use \u0026mySlice[i] for a stable address\n  }\n  ```\n- **Do not** store the address of the iteration variable. This practice leads to all references pointing to the same location in memory, causing errors.\n- **Do not** use the iteration variable's address in goroutines. This can result in race conditions or logical errors if the variable's value changing before the goroutine accesses it.\n\n## References\n\n- [Go For Statements](https://go.dev/ref/spec#For_statements)"}},{"id":"go_lang_html_tag_injection","name":"go_lang_html_tag_injection","shortDescription":{"text":"Missing sanitization of HTML template tags"},"fullDescription":{"text":"Missing sanitization of HTML template tags"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nWhen user input is not sanitized, attackers can inject HTML tags, such as `\u003cscript\u003e` tags, into templates. This unsanitized input can lead to Cross-Site Scripting (XSS) attacks when the malicious scripts are executed.\n\n## Remediations\n\n- **Do** sanitize user input before incorporating it into a template. This step is crucial to prevent XSS attacks.\n  ```go\n  safe := template.HTMLEscapeString(r.FormValue(\"xyz\"))\n  ```\n- **Do** use `html/template` instead of `text/template` for parsing and rendering templates. The `html/template` package automatically escapes inputs, providing an additional layer of security.\n  ```go\n  import \"html/template\"\n\n  func good(w http.ResponseWriter, r *http.Request) {\n    t, _ := template.New(\"something\").Parse(r.FormValue(\"xyz\"))\n    t.Execute(w, nil)\n  }\n  ```\n\n## References\n\n- [OWASP XSS Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)","markdown":"## Description\n\nWhen user input is not sanitized, attackers can inject HTML tags, such as `\u003cscript\u003e` tags, into templates. This unsanitized input can lead to Cross-Site Scripting (XSS) attacks when the malicious scripts are executed.\n\n## Remediations\n\n- **Do** sanitize user input before incorporating it into a template. This step is crucial to prevent XSS attacks.\n  ```go\n  safe := template.HTMLEscapeString(r.FormValue(\"xyz\"))\n  ```\n- **Do** use `html/template` instead of `text/template` for parsing and rendering templates. The `html/template` package automatically escapes inputs, providing an additional layer of security.\n  ```go\n  import \"html/template\"\n\n  func good(w http.ResponseWriter, r *http.Request) {\n    t, _ := template.New(\"something\").Parse(r.FormValue(\"xyz\"))\n    t.Execute(w, nil)\n  }\n  ```\n\n## References\n\n- [OWASP XSS Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)"}},{"id":"go_gorilla_insecure_cookie","name":"go_gorilla_insecure_cookie","shortDescription":{"text":"Missing Secure option in cookie configuration"},"fullDescription":{"text":"Missing Secure option in cookie configuration"},"defaultConfiguration":{"level":"error"},"help":{"text":"## Description\n\nThe Secure attribute in cookie configuration is crucial for protecting cookies from unauthorized third-party access. When set to \"true,\" it ensures cookies are only sent over HTTPS, safeguarding the data during transmission.\n\n## Remediations\n\n- **Do** set the Secure flag for cookies if your site uses HTTPS. This action restricts cookies to secure channels, enhancing their security.\n  ```go\n  http.SetCookie(w, \u0026http.Cookie{\n      Name:     \"session_token\",\n      Value:    sessionToken,\n      Secure:   true,\n      HttpOnly: true,\n  })\n  ```\n- **Do** use Gorilla SecureCookie for encoding and decoding session data securely. This method provides an additional layer of security for session information.\n  ```go\n  var s = sessions.NewCookieStore([]byte(\"your-secret-key\"))\n  ```\n- **Do** implement robust session management with Gorilla Sessions. Proper session management helps prevent attacks related to session fixation and enhances overall session security.\n\n## References\n\n- [Gorilla Sessions Documentation](http://www.gorillatoolkit.org/pkg/sessions)\n- [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)\n- [OWASP Cookies Properties](https://owasp.org/www-community/controls/SecureCookieAttribute)","markdown":"## Description\n\nThe Secure attribute in cookie configuration is crucial for protecting cookies from unauthorized third-party access. When set to \"true,\" it ensures cookies are only sent over HTTPS, safeguarding the data during transmission.\n\n## Remediations\n\n- **Do** set the Secure flag for cookies if your site uses HTTPS. This action restricts cookies to secure channels, enhancing their security.\n  ```go\n  http.SetCookie(w, \u0026http.Cookie{\n      Name:     \"session_token\",\n      Value:    sessionToken,\n      Secure:   true,\n      HttpOnly: true,\n  })\n  ```\n- **Do** use Gorilla SecureCookie for encoding and decoding session data securely. This method provides an additional layer of security for session information.\n  ```go\n  var s = sessions.NewCookieStore([]byte(\"your-secret-key\"))\n  ```\n- **Do** implement robust session management with Gorilla Sessions. Proper session management helps prevent attacks related to session fixation and enhances overall session security.\n\n## References\n\n- [Gorilla Sessions Documentation](http://www.gorillatoolkit.org/pkg/sessions)\n- [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)\n- [OWASP Cookies Properties](https://owasp.org/www-community/controls/SecureCookieAttribute)"}}]}},"results":[{"ruleId":"go_gosec_filesystem_filereadtaint","message":{"text":"Unsanitized user input in file path"},"locations":[{"physicalLocation":{"artifactLocation":{"uri":"internal/config/config.go"},"region":{"startLine":41,"startColumn":15,"endColumn":32,"endLine":41}}}],"partialFingerprints":{"primaryLocationLineHash":"690cb9207bb6cb72edd1002fae0a0fa3_0"}},{"ruleId":"go_lang_logger_leak","message":{"text":"Leakage of information in logger message"},"locations":[{"physicalLocation":{"artifactLocation":{"uri":"cmd/add_user/main.go"},"region":{"startLine":33,"startColumn":3,"endColumn":72,"endLine":33}}}],"partialFingerprints":{"primaryLocationLineHash":"219087ffdfad090e6436320f68eae990_0"}},{"ruleId":"go_lang_logger_leak","message":{"text":"Leakage of information in logger message"},"locations":[{"physicalLocation":{"artifactLocation":{"uri":"cmd/add_user/main.go"},"region":{"startLine":41,"startColumn":3,"endColumn":101,"endLine":41}}}],"partialFingerprints":{"primaryLocationLineHash":"219087ffdfad090e6436320f68eae990_1"}},{"ruleId":"go_lang_logger_leak","message":{"text":"Leakage of information in logger message"},"locations":[{"physicalLocation":{"artifactLocation":{"uri":"cmd/authapp/main.go"},"region":{"startLine":33,"startColumn":3,"endColumn":82,"endLine":33}}}],"partialFingerprints":{"primaryLocationLineHash":"533ab12ca2b781f58bc69e81cb601ad6_0"}},{"ruleId":"go_lang_logger_leak","message":{"text":"Leakage of information in logger message"},"locations":[{"physicalLocation":{"artifactLocation":{"uri":"cmd/authapp/main.go"},"region":{"startLine":43,"startColumn":3,"endColumn":72,"endLine":43}}}],"partialFingerprints":{"primaryLocationLineHash":"533ab12ca2b781f58bc69e81cb601ad6_1"}},{"ruleId":"go_lang_logger_leak","message":{"text":"Leakage of information in logger message"},"locations":[{"physicalLocation":{"artifactLocation":{"uri":"cmd/init_users/main.go"},"region":{"startLine":18,"startColumn":3,"endColumn":72,"endLine":18}}}],"partialFingerprints":{"primaryLocationLineHash":"448b1db1ab73e2474723c4d659611644_0"}}]}]}