Integrity Failures in Fiber
How Integrity Failures Manifests in Fiber
Integrity Failures in Fiber applications occur when an attacker manipulates data or state in ways the application didn't anticipate. In Go's Fiber framework, these vulnerabilities often manifest through improper authorization checks and inadequate validation of user-supplied identifiers.
The most common pattern involves IDOR (Insecure Direct Object Reference) attacks where an authenticated user can access or modify resources belonging to other users by simply changing an ID parameter in the request. Consider this vulnerable Fiber route:
app.Get("/api/users/:id", func(c *fiber.Ctx) error {
id := c.Params("id")
user, err := db.GetUser(id)
if err != nil {
return c.Status(404).SendString("User not found")
}
return c.JSON(user)
})This endpoint allows any authenticated user to view any user's profile by changing the ID parameter. The vulnerability stems from missing authorization checks to verify the requesting user has permission to access the requested resource.
Another Fiber-specific manifestation involves improper validation of array parameters. When handling batch operations, developers often forget to validate each element:
app.Post("/api/users/delete-multiple", func(c *fiber.Ctx) error {
var ids []string
if err := c.BodyParser(&ids); err != nil {
return c.Status(400).SendString("Invalid input")
}
for _, id := range ids {
db.DeleteUser(id) // No authorization check per ID!
}
return c.SendString("Users deleted")
})This endpoint processes all IDs without verifying the requesting user owns or has permission to delete each resource. An attacker can delete arbitrary users by including their IDs in the request.
Fiber's middleware system can also introduce integrity failures if not properly configured. For example, a custom authentication middleware that only checks for a valid session token but doesn't verify resource ownership:
func AuthMiddleware(c *fiber.Ctx) error {
token := c.Get("Authorization")
if token == "" {
return c.Status(401).SendString("Unauthorized")
}
// Validate token exists but don't check resource ownership
c.Locals("userID", tokenUserID)
return c.Next()
}This middleware authenticates the request but fails to enforce authorization, allowing authenticated users to access any resource they can reference by ID.
Fiber-Specific Detection
Detecting Integrity Failures in Fiber applications requires both manual code review and automated scanning. The most effective approach combines static analysis of your Go code with dynamic runtime testing.
Manual detection should focus on identifying patterns where user input directly controls resource access. Look for routes that accept IDs or other identifiers without proper authorization checks. In Fiber, this often appears in handlers that use c.Params(), c.Query(), or c.BodyParser() without subsequent validation.
Automated detection with middleBrick provides comprehensive coverage by testing your API endpoints without requiring source code access. middleBrick's black-box scanning methodology specifically targets the unauthenticated attack surface, testing for common integrity failure patterns:
# Scan your Fiber API with middleBrick
middlebrick scan https://api.yourservice.com
# Or integrate into your CI/CD pipeline
middlebrick scan --threshold B --fail-below C https://staging.api.yourservice.commiddleBrick tests 12 security categories in parallel, including Authentication, BOLA/IDOR, BFLA/Privilege Escalation, and Property Authorization. For Fiber applications, it specifically looks for:
- IDOR vulnerabilities where changing numeric or UUID parameters returns different user data
- Missing authorization checks in CRUD operations
- Property-level authorization failures where users can view or modify fields they shouldn't access
- Batch operation vulnerabilities where multiple resources are processed without per-item validation
The scanner generates a security risk score (0-100) with letter grades and provides actionable findings with severity levels and remediation guidance. For Fiber APIs, middleBrick can detect if your endpoints are vulnerable to common attack patterns without requiring any configuration or credentials.
During development, you can also use Fiber's built-in middleware for basic protection. The cors middleware helps prevent certain types of cross-origin attacks, though it doesn't address integrity failures directly:
import "github.com/gofiber/fiber"
import "github.com/gofiber/fiber/middleware/cors"
app := fiber.New()
app.Use(cors.New())Fiber-Specific Remediation
Remediating Integrity Failures in Fiber requires implementing proper authorization checks and input validation. The most effective approach is to verify resource ownership at the application level before processing any request that references user-specific data.
For individual resource access, implement authorization middleware that validates the requesting user owns the target resource:
func AuthorizeUserResource(c *fiber.Ctx) error {
id := c.Params("id")
userID := c.Locals("userID").(string)
// Verify the resource belongs to the requesting user
resource, err := db.GetUserResource(id)
if err != nil || resource.UserID != userID {
return c.Status(403).SendString("Forbidden")
}
c.Locals("resource", resource)
return c.Next()
}
app.Get("/api/users/:id", AuthorizeUserResource, func(c *fiber.Ctx) error {
resource := c.Locals("resource").(*UserResource)
return c.JSON(resource)
})This pattern ensures users can only access their own resources, regardless of what ID they provide in the request.
For batch operations, validate each item individually before processing:
app.Post("/api/users/delete-multiple", func(c *fiber.Ctx) error {
var ids []string
if err := c.BodyParser(&ids); err != nil {
return c.Status(400).SendString("Invalid input")
}
userID := c.Locals("userID").(string)
// Validate each ID belongs to the requesting user
for _, id := range ids {
resource, err := db.GetUserResource(id)
if err != nil || resource.UserID != userID {
return c.Status(403).SendString("Forbidden: invalid resource ID")
}
}
// All IDs validated, now perform deletion
for _, id := range ids {
db.DeleteUserResource(id)
}
return c.SendString("Resources deleted")
})This approach prevents attackers from including arbitrary IDs in batch requests.
For complex authorization scenarios, consider using a dedicated authorization library or implementing role-based access control (RBAC). Fiber's middleware system makes it easy to compose multiple authorization checks:
func RequirePermission(permission string) fiber.Handler {
return func(c *fiber.Ctx) error {
user := c.Locals("user").(*User)
if !user.HasPermission(permission) {
return c.Status(403).SendString("Insufficient permissions")
}
return c.Next()
}
}
app.Get("/api/admin/users",
RequirePermission("admin:read"),
func(c *fiber.Ctx) error {
users, _ := db.GetAllUsers()
return c.JSON(users)
})
app.Post("/api/admin/users",
RequirePermission("admin:create"),
func(c *fiber.Ctx) error {
var newUser User
if err := c.BodyParser(&newUser); err != nil {
return c.Status(400).SendString("Invalid input")
}
db.CreateUser(&newUser)
return c.JSON(newUser)
})This pattern separates authentication (who you are) from authorization (what you can do), providing granular control over API access.
Finally, implement comprehensive input validation using Go's standard library or validation packages. Never trust user input, even when it appears to be numeric IDs:
import "github.com/go-playground/validator/v10"
validate := validator.New()
type DeleteRequest struct {
IDs []string `validate:"required,dive,uuid"`
}
app.Post("/api/resources/delete", func(c *fiber.Ctx) error {
var req DeleteRequest
if err := c.BodyParser(&req); err != nil {
return c.Status(400).SendString("Invalid JSON")
}
if err := validate.Struct(req); err != nil {
return c.Status(400).SendString("Invalid input format")
}
// Continue with authorization checks...
return c.SendString("Processing...")
})