Fix Improper Error Handling in Revel

Revel's default error handling is a reconnaissance goldmine. Out-of-the-box, it leaks stack traces, file paths, and database schema hints via RenderError. In a production environment, verbose errors allow attackers to map your internal logic and identify vulnerable dependencies. Proper error handling requires stripping sensitive metadata before it hits the wire and ensuring 'app.conf' is hardened for production.

The Vulnerable Pattern

func (c App) ShowUser(id int) revel.Result {
    user, err := db.FindUser(id)
    if err != nil {
        // VULNERABLE: Directly passing the raw error object to RenderError.
        // If the DB is down or the query fails, the user sees the full SQL driver error and stack trace.
        return c.RenderError(err)
    }
    return c.RenderJSON(user)
}

The Secure Implementation

Fixing this requires a two-pronged approach: code-level sanitization and configuration hardening. First, never pass raw 'error' objects to 'c.RenderError' in public-facing controllers; instead, log the error using 'revel.AppLog' and return a generic 500 template. Second, audit your 'app.conf'. Ensure 'results.pretty = false' and 'errors.show_details = false' are set for the production profile. This prevents Revel's built-in error interceptors from rendering the 'Panic Page' which exposes source code snippets to the end user.

func (c App) ShowUser(id int) revel.Result {
    user, err := db.FindUser(id)
    if err != nil {
        // SECURE: Log the detailed error internally for debugging
        revel.AppLog.Errorf("Failed to fetch user %d: %v", id, err)
    // Return a generic error message to the client
    c.Response.Status = 500
    return c.RenderTemplate("errors/500.html")
}
return c.RenderJSON(user)
}