HIGH null pointer dereferencefiber

Null Pointer Dereference in Fiber

How Null Pointer Dereference Manifests in Fiber

Null pointer dereference in Fiber applications typically occurs when handlers assume request context values exist without validation. Fiber's c.Get(), c.Params(), and c.Query() methods return empty strings rather than nil for missing values, but developers often dereference pointers from these values or from JSON unmarshaling without checking.

func getUser(c *fiber.Ctx) error {
    id := c.Params("id")
    user := database.FindUserByID(id) // id might be empty string
    return c.JSON(user.Name) // user could be nil, causing panic
}

This pattern is particularly dangerous in middleware chains where later handlers assume earlier middleware has set required context values. A missing authentication middleware or failed database connection can leave context values unset, causing downstream handlers to panic when dereferencing nil pointers.

func requireAuth(c *fiber.Ctx) error {
    token := c.Get("Authorization")
    if token == "" {
        return c.Status(401).SendString("Unauthorized")
    }
    // Missing: setting user in context on failure
    return c.Next()
}

func profileHandler(c *fiber.Ctx) error {
    user := c.Locals("user").(*User) // nil pointer dereference if auth failed
    return c.JSON(user)
}

JSON body parsing also introduces null pointer risks when unmarshaling into structs with pointer fields. If the client omits a field or sends null, the pointer remains nil and subsequent code may panic when dereferencing.

type CreateUserRequest struct {
    Email *string `json:"email"`
    Age   *int    `json:"age"`
}

func createUser(c *fiber.Ctx) error {
    var req CreateUserRequest
    if err := c.BodyParser(&req); err != nil {
        return err
    }
    
    email := *req.Email // panic if email is nil
    age := *req.Age     // panic if age is nil
    
    return c.JSON(database.CreateUser(email, age))
}

Fiber-Specific Detection

middleBrick's black-box scanning approach detects null pointer dereference vulnerabilities by sending malformed requests that trigger Fiber's error handling paths. The scanner tests for missing required parameters, empty JSON bodies, and invalid content types to surface handlers that don't validate input properly.

For Fiber applications, middleBrick specifically checks:

  • Parameter extraction methods that return empty strings but are treated as valid pointers
  • JSON unmarshaling into pointer fields without nil checks
  • Context value access patterns where locals might not be set
  • Middleware chains where later handlers assume earlier middleware success
  • Database query results that might return nil without validation

The scanner sends requests with missing path parameters, empty JSON bodies, and invalid content types to trigger error paths. For example, it tests handlers like:

app.Get("/user/:id", func(c *fiber.Ctx) error {
    id := c.Params("id")
    if id == "" {
        return c.Status(400).SendString("Missing ID")
    }
    user := database.FindUserByID(id)
    if user == nil {
        return c.Status(404).SendString("Not found")
    }
    return c.JSON(user)
})

middleBrick's LLM security module also detects if your Fiber application serves AI endpoints vulnerable to prompt injection attacks that could manipulate null pointer handling in downstream services.

Fiber-Specific Remediation

Proper null pointer handling in Fiber requires defensive programming patterns. Always validate request parameters and check database results before dereferencing. Use Fiber's built-in validation and error handling to create robust APIs.

func getUserSafe(c *fiber.Ctx) error {
    id := c.Params("id")
    if id == "" {
        return c.Status(400).SendString("User ID is required")
    }
    
    user := database.FindUserByID(id)
    if user == nil {
        return c.Status(404).SendString("User not found")
    }
    
    return c.JSON(user)
}

For JSON parsing with pointer fields, use validation middleware or check pointers before dereferencing:

func createUserSafe(c *fiber.Ctx) error {
    var req CreateUserRequest
    if err := c.BodyParser(&req); err != nil {
        return c.Status(400).SendString("Invalid JSON")
    }
    
    if req.Email == nil || req.Age == nil {
        return c.Status(400).SendString("Email and age are required")
    }
    
    return c.JSON(database.CreateUser(*req.Email, *req.Age))
}

Middleware should always set context values or return errors, never leave them unset:

func requireAuth(c *fiber.Ctx) error {
    token := c.Get("Authorization")
    if token == "" {
        return c.Status(401).SendString("Unauthorized")
    }
    
    user, err := auth.ValidateToken(token)
    if err != nil {
        return c.Status(401).SendString("Invalid token")
    }
    
    c.Locals("user", user)
    return c.Next()
}

middleBrick's CLI tool helps validate your fixes by scanning the API after remediation:

middlebrick scan https://api.example.com --fail-below B

This ensures your null pointer dereference fixes are properly implemented before deployment to production.

Frequently Asked Questions

Why does Fiber return empty strings instead of nil for missing parameters?
Fiber's design philosophy prioritizes developer convenience by returning empty strings for missing parameters rather than nil pointers. This prevents immediate panics but requires developers to implement their own validation logic. Always check if required parameters are empty strings before using them in database queries or business logic.
Can middleBrick detect null pointer dereferences in compiled Go binaries?
middleBrick uses black-box scanning and cannot directly analyze compiled binaries. However, it detects the runtime symptoms of null pointer dereferences by sending malformed requests that trigger error paths. The scanner identifies patterns where missing validation could lead to panics, even without source code access.