Bola Idor in Fiber with Cockroachdb

Broken Object Level Authorization (BOLA) occurs when an API fails to enforce authorization checks at the object level, allowing one user to access or modify another user’s resources. When building a Fiber API with CockroachDB as the backend, this risk is amplified if route parameters such as :id are used directly to construct database queries without validating ownership or permissions.

Consider a typical endpoint /users/:id/profile. If the handler retrieves the user record using only the URL parameter and returns the profile without confirming the requesting user matches :id, the endpoint is vulnerable. CockroachDB, being a distributed SQL database, does not provide application-level authorization; it enforces SQL semantics and access control at the database user level. Therefore, responsibility for ensuring that a requestor can only access their own data lies with the API layer. A vulnerable Fiber handler might look like:

// Vulnerable: uses :id without ownership check
app.get('/users/:id/profile', async (c) => {
  const id = c.params('id');
  var row = await db.queryRow(c.Request().Context(), 'SELECT id, display_name, email FROM profiles WHERE user_id = $1', id);
  return c.JSON(row);
});

An attacker can change :id to enumerate other profiles because the query does not bind the request context (e.g., authenticated user ID) to the filter. Even if the database has role-based access controls, they are typically too coarse for per-object checks. This creates BOLA because the API trusts the client-supplied identifier instead of enforcing a relationship between the authenticated subject and the resource identifier.

Moreover, if the API exposes secondary endpoints that perform mutations (PUT/DELETE) using the same pattern, the vulnerability becomes actionable for unauthorized updates or data exfiltration. For example, an attacker could attempt to update or delete another user’s profile by sending a crafted request to /users/123/settings where 123 does not belong to them. CockroachDB will execute the statement unless the application layer prevents it. In distributed deployments, network latency and serialization do not mitigate missing authorization; they only change the timing of exposure. The combination of Fiber’s lightweight routing, CockroachDB’s SQL interface, and missing object-level checks is a common path to BOLA.

Remediation requires ensuring that every data access ties the query to the authenticated subject. Do not rely on client-supplied identifiers for ownership. Instead, resolve the subject from the request context (e.g., JWT claims or session) and use it in the WHERE clause.

Below is a secure Fiber handler that retrieves a profile using the authenticated user’s identity rather than the URL parameter for authorization. The URL parameter can still be used for lookup, but it must be cross-checked against the subject ID.

// Secure: bind authenticated user ID from context
app.get('/users/:id/profile', async (c) => {
  // Assume auth sets c.Locals().Get('user') with a Claims struct containing ID
  claims, ok := c.Locals().Get('user').(Claims);
  if !ok {
    return c.Status(401).JSON(map[string]string{"error": "unauthorized"});
  }
  requestedID := c.Params('id');
  // Enforce ownership: the requested ID must match the authenticated subject
  if requestedID != claims.ID {
    return c.Status(403).JSON(map[string]string{"error": "forbidden"});
  }
  var row struct {
    ID          string;
    DisplayName string;
    Email       string;
  };
  err := db.QueryRow(c.Request().Context(),
    'SELECT id, display_name, email FROM profiles WHERE user_id = $1',
    claims.ID).Scan(&row.ID, &row.DisplayName, &row.Email);
  if err != nil {
    return c.Status(404).JSON(map[string]string{"error": "not found"});
  }
  return c.JSON(row);
});

For mutations, apply the same pattern. Do not allow a user to modify another user’s resource by trusting :id alone. Use the authenticated subject to drive the update and optionally verify existence and ownership in a single query.

// Secure update with ownership check
app.put('/users/:id/settings', async (c) => {
  claims, ok := c.Locals().Get('user').(Claims);
  if !ok {
    return c.Status(401).JSON(map[string]string{"error": "unauthorized"});
  }
  requestedID := c.Params('id');
  if requestedID != claims.ID {
    return c.Status(403).JSON(map[string]string{"error": "forbidden"});
  }
  var input struct {
    Theme string;
    Locale string;
  }
  if err := c.BodyParser(&input); err != nil {
    return c.Status(400).JSON(map[string]string{"error": "invalid payload"});
  }
  res, err := db.Exec(c.Request().Context(),
    'UPDATE users SET theme = $1, locale = $2 WHERE id = $3 AND id = $3',
    input.Theme, input.Locale, claims.ID);
  if err != nil {
    return c.Status(500).JSON(map[string]string{"error": "server error"});
  }
  rows, _ := res.RowsAffected();
  if rows == 0 {
    return c.Status(404).JSON(map[string]string{"error": "not found"});
  }
  return c.JSON(map[string]string{"status": "ok"});
});

Additional hardening steps specific to CockroachDB include using placeholders consistently to avoid SQL injection and ensuring that usernames or emails are not used directly as identifiers in the URL. Prefer UUIDs or integer IDs for :id, and validate format before using them in queries. Also consider row-level security (RLS) at the database layer as a defense-in-depth measure, but remember that RLS should complement, not replace, application-level authorization checks in Fiber.