Error unhandled

ID

go.error_unhandled

Severity

low

Resource

Risky Values

Language

Go

Tags

CWE:252, NIST.SP.800-53, OWASP:2021:A1, PCI-DSS:6.5.8

Description

Failure to handle returned errors in Go can lead to unexpected behavior, silent failures, and security issues if the application continues execution after a critical operation fails.

Rationale

In Go, error handling is explicit and idiomatic. Functions frequently return an error value that must be checked to determine whether an operation succeeded. Ignoring or discarding this value can allow the application to proceed in an invalid or insecure state.

This vulnerability aligns with CWE-252 (Unchecked Return Value), where the developer calls a function that returns a value indicating success or failure but does not verify that value. In security-sensitive operations (e.g., file I/O, cryptography, network requests), ignoring errors may result in:

  • Incomplete security checks

  • Open file or socket leaks

  • Data loss or corruption

  • Broken authentication or authorization flow

  • Silent failure of security mechanisms === Example 1: Unhandled file write error

f, _ := os.Create("data.txt") // FLAW
defer f.Close()

f.Write([]byte("Important data")) // FLAW

If os.Create fails (e.g., due to permission issues), the application may crash later or silently fail to write data.

Example 2: Ignoring errors from JSON unmarshaling

json.Unmarshal([]byte(userInput), &target) // FLAW

An attacker could send malformed JSON, and the application might continue using partially filled or default-initialized data structures, leading to logic flaws or security bypasses.

Example 3: Unchecked cryptographic operations

ciphertext, _ := rsa.EncryptPKCS1v15(rand.Reader, pubKey, data) // FLAW

If encryption fails (due to a nil key, bad randomness, etc.), the code may incorrectly assume it has valid ciphertext, which compromises confidentiality.

Remediation

  • Always check the error returned from functions that return (T, error) or error.

f, err := os.Create("data.txt")
if err != nil {
    log.Printf("Failed to create file: %v", err)
    return
}
defer f.Close()

  • Propagate or handle the error explicitly depending on the function’s responsibility.

    • For internal helpers, return the error upstream.

    • For top-level handlers (e.g., HTTP), log or respond accordingly.

  • Do not use _ to discard errors silently. Reserve it for values you are absolutely sure are safe to ignore (rare in security-sensitive code).

  • Use static analysis tools to detect unhandled errors.

    • Go has built-in vetting tools (go vet) and linters (staticcheck, golangci-lint) that catch unhandled errors.

    • SAST tools can extend detection to security-relevant operations, e.g., crypto, net, os.

  • Enforce error handling in code reviews and CI. Consistency in error checking improves code robustness and mitigates silent security failures.

Configuration

The detector has the following configurable parameters:

  • ignoredErrors, that indicates a white-list of functions that return error but is acceptable to not checking them.

  • ignoreDeferredErrors, that indicates if the deferred errors should be ignored or not.

References