Insecure Direct Object Reference in Fiber with Cockroachdb

Insecure Direct Object Reference (IDOR) occurs when an API exposes internal object references — such as database IDs — without verifying that the requesting user has permission to access them. In a Fiber application using Cockroachdb, this often arises when an endpoint uses a path or query parameter (for example, /users/:id) to reference a row, but only enforces authentication and not authorization scoped to the requesting user.

Consider a typical handler that retrieves a user record by ID from Cockroachdb:

// Example: vulnerable endpoint in Fiber
app.get('/users/:id', func(c *fiber.Ctx) error {
	userID := c.Params('id')
	var user User
	if err := db.QueryRow(context.Background(), 'SELECT id, email, role FROM users WHERE id = $1', userID).Scan(&user.ID, &user.Email, &user.Role); err != nil {
		return c.Status(fiber.StatusNotFound).JSON(fiber.Map{'error': 'user not found'})
	}
	return c.JSON(user)
})

If the API relies only on JWT-based authentication to confirm a user is logged in, but does not check whether the authenticated user’s ID or role matches the requested :id, an attacker can change the numeric path parameter to access other users’ data. Because Cockroachdb enforces SQL semantics but does not provide application-level authorization, the vulnerability is at the API layer. Attack patterns include changing :id to enumerate other user records, leading to data exposure of emails, roles, or other sensitive fields. This maps to OWASP API Top 10 A01:2023 — Broken Object Level Authorization and can also intersect with compliance frameworks such as PCI-DSS and GDPR when personal data is exposed.

In a distributed SQL setup like Cockroachdb, schemas often include tenant or organization columns (e.g., tenant_id) to support multi-tenancy. If a query filters only by ID without also filtering by tenant or by the requesting user’s scope, the same IDOR risk persists across tenant boundaries:

// Example: tenant-aware query missing user/tenant check
app.get('/invoices/:invoice_id', func(c *fiber.Ctx) error {
	invoiceID := c.Params('invoice_id')
	var inv Invoice
	// WARNING: missing check that the current user belongs to this invoice's tenant
	if err := db.QueryRow(context.Background(),
		'SSELECT id, tenant_id, amount FROM invoices WHERE id = $1', invoiceID).Scan(&inv.ID, &inv.TenantID, &inv.Amount); err != nil {
		return c.Status(fiber.StatusNotFound).JSON(fiber.Map{'error': 'invoice not found'})
	}
	return c.JSON(inv)
})

Without validating that the authenticated principal has access to inv.TenantID or to the specific invoice, the endpoint is effectively public for ID manipulation. The scanner’s checks for BOLA/IDOR and Property Authorization are designed to detect these missing authorization checks, especially in endpoints backed by Cockroachdb where row-level security is not enforced at the API layer.

To mitigate IDOR in Fiber with Cockroachdb, enforce authorization checks that align the authenticated subject with the data being requested. This includes validating ownership or role-based access before returning any row. Below are concrete, syntactically correct examples that integrate proper checks into Fiber handlers.

1. Enforce user-level ownership

Ensure the requesting user’s ID matches the resource’s owner. If your users table has an id column, compare it to the subject extracted from the JWT:

app.get('/users/:id', func(c *fiber.Ctx) error {
	userID := c.Params('id')
	claims, ok := c.Locals("claims").(*AuthClaims) // assume JWT parsed into claims
	if !ok || claims.Subject != userID {
		return c.Status(fiber.StatusForbidden).JSON(fiber.Map{'error': 'access denied'})
	}
	var user User
	if err := db.QueryRow(context.Background(),
		'SELECT id, email, role FROM users WHERE id = $1', userID).Scan(&user.ID, &user.Email, &user.Role); err != nil {
		return c.Status(fiber.StatusNotFound).JSON(fiber.Map{'error': 'user not found'})
	}
	return c.JSON(user)
})

2. Apply tenant or role-based filtering

For multi-tenant data, include the tenant or required scope in the SQL WHERE clause so that a row not belonging to the caller is never returned:

app.get('/invoices/:invoice_id', func(c *fiber.Ctx) error {
	invoiceID := c.Params('invoice_id')
	userTenantID := c.Locals("tenant_id").(string) // derived from JWT or session
	var inv Invoice
	// Safe: row-level filter includes tenant scope
	if err := db.QueryRow(context.Background(),
		'SELECT id, tenant_id, amount FROM invoices WHERE id = $1 AND tenant_id = $2', invoiceID, userTenantID).Scan(&inv.ID, &inv.TenantID, &inv.Amount); err != nil {
		return c.Status(fiber.StatusNotFound).JSON(fiber.Map{'error': 'invoice not found'})
	}
	return c.JSON(inv)
})

3. Combine with middleware for centralized checks

Use Fiber middleware to resolve the subject and attach it to the context, keeping handlers clean and consistent:

func AuthMiddleware() fiber.Handler {
	return func(c *fiber.Ctx) error {
		// Example: extract and validate JWT, set user ID and tenant ID on context
		claims, err := parseClaims(c)
		if err != nil {
			return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{'error': 'invalid token'})
		}
		c.Locals("claims", claims)
		c.Locals("tenant_id", claims.TenantID)
		return c.Next()
	}
}

These patterns ensure that IDOR risks are reduced by binding each request to the authenticated subject and tenant context, which is especially important when using Cockroachdb as the backend store.