Bola Idor on Digitalocean

Broken Object Level Authorization (BOLA), also referenced as IDOR in the OWASP API Security Top 10 (API1:2023), occurs when an API endpoint uses a user‑supplied identifier to retrieve or modify a resource without verifying that the identifier belongs to the requesting party. In the DigitalOcean API, many endpoints are structured around numeric or UUID identifiers (e.g., droplet IDs, volume IDs, snapshot IDs). If a developer builds a wrapper or internal service that forwards the raw identifier to the DigitalOcean endpoint without an ownership check, an attacker can enumerate or guess valid IDs and access or manipulate resources that belong to other accounts or projects.

Typical vulnerable patterns include:

• Droplet retrieval via user‑provided ID: A custom admin portal exposes GET /internal/droplets/:id that simply proxies to https://api.digitalocean.com/v2/droplets/:id using the account’s API token. The portal does not verify that the droplet belongs to the current team or project, allowing a malicious user to substitute another user’s droplet ID and view its details, power state, or even issue power‑on/off commands.
• Volume attachment/detachment: An internal tool accepts a volume ID and a droplet ID to attach storage. If the tool only checks that the volume exists but not that it is owned by the same team as the droplet, an attacker can attach a volume belonging to another customer to their own droplet, leading to data leakage.
• Snapshot creation from arbitrary droplet IDs: A CI pipeline step that creates a snapshot uses a droplet ID supplied from a previous job. Without confirming the droplet is part of the pipeline’s own project, an attacker could trigger a snapshot of a foreign droplet and later download it, exposing sensitive data.

These scenarios map directly to the OWASP API1:2023 definition of BOLA and have been observed in real‑world cloud‑service integrations, resulting in CVEs such as CVE-2020-13942 (Zoom) and CVE-2021-22986 (F5 BIG‑IP) where insufficient object‑level checks allowed unauthorized data access.

Detecting BOLA/IDOR in a DigitalOcean‑centric API requires probing the unauthenticated or low‑privilege attack surface for endpoints that accept an identifier and return resource‑specific data. middleBrick performs this by sending a series of crafted requests against the target URL, varying the identifier while keeping authentication (if any) constant, and analysing the responses for signs of unauthorized access.

When you run a scan via the middleBrick CLI, the tool automatically:

• Discovers all reachable endpoints under the supplied base URL (e.g., https://api.example.com).
• For each endpoint that contains a path parameter resembling an ID (numeric, UUID, or alphanumeric), it substitutes the value with a sequence of incremental numbers or known‑bad UUIDs.
• It compares the response status codes, bodies, and headers to the baseline request. A successful BOLA is flagged when:
• The substituted ID returns a 200 OK with a resource representation that differs from the baseline (e.g., different droplet name, region, or tags).
• The response leaks fields that should be restricted (e.g., image.id, volume.size, snapshot.min_disk_size).
• The endpoint accepts HTTP methods that modify state (POST, PATCH, DELETE) and the substituted ID leads to a state change without an authorization error.
• Findings are reported with a severity rating (usually high for BOLA) and include the exact URL, the parameter name, the original and test values, and a short remediation note.

Example CLI command:

middlebrick scan https://api.mycompany.com/internal

The output JSON will contain an entry similar to:

{
  "id": "bola-001",
  "name": "Potential BOLA/IDOR on droplet ID parameter",
  "severity": "high",
  "location": {
    "method": "GET",
    "path": "/internal/droplets/:droplet_id"
  },
  "evidence": {
    "baseline_response": {
      "status": 200,
      "body": {"droplet":{"id":12345678,"name":"prod-web-01","region":"nyc1"}}
    },
    "test_response": {
      "status": 200,
      "body": {"droplet":{"id":87654321,"name":"dev-db-02","region":"sfo2"}}
    }
  },
  "remediation": "Ensure the requesting user/project owns the droplet before returning data. Validate ownership by checking the droplet’s `tags` or by calling `/v2/droplets/:id` with the user’s token and confirming the response belongs to the same account."
}

Integrating the same check into CI/CD is straightforward with the GitHub Action:

name: API Security Scan
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run middleBrick scan
        uses: middlebrick/action@v1
        with:
          api-url: https://api.mycompany.com/internal
          fail-below: B   # fail the job if score drops below B

This action will automatically fail a pull request when a new BOLA/IDOR is introduced, giving developers immediate feedback before code reaches production.

Fixing BOLA/IDOR in services that interact with the DigitalOcean API requires adding an explicit ownership verification step before forwarding the identifier to the DigitalOcean endpoint. The verification can be performed using the same API token that the service already possesses, ensuring that the token is authorized to act on the resource in question.

Below are concrete remediation examples for common languages and libraries used with DigitalOcean.

Go (using the official github.com/digitalocean/godo client)

Suppose a handler receives a droplet ID from the request and returns its details. The vulnerable version might look like:

func getDroplet(w http.ResponseWriter, r *http.Request) {
    vars := mux.Vars(r)
    id := vars["droplet_id"]
    droplet, _, err := client.Droplets.Get(context.Background(), id)
    if err != nil {
        http.Error(w, err.Error(), http.StatusNotFound)
        return
    }
    json.NewEncoder(w).Encode(droplet)
}

The fix adds an ownership check by verifying that the droplet belongs to the current team or project. DigitalOcean does not expose a direct "owner" field, but you can compare the droplet’s tags (which you control) or list all droplets for the account and ensure the ID appears in that list.

func getDroplet(w http.ResponseWriter, r *http.Request) {
    vars := mux.Vars(r)
    idStr := vars["droplet_id"]
    id, err := strconv.Atoi(idStr)
    if err != nil {
        http.Error(w, "invalid droplet ID", http.StatusBadRequest)
        return
    }
    // List droplets for the account (or team) using the same token
    droplets, _, err := client.Droplets.List(context.Background(), &godo.ListOptions{})
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
    authorized := false
    for _, d := range droplets {
        if d.ID == id {
            authorized = true
            break
        }
    }
    if !authorized {
        http.Error(w, "forbidden", http.StatusForbidden)
        return
    }
    droplet, _, err := client.Droplets.Get(context.Background(), id)
    if err != nil {
        http.Error(w, err.Error(), http.StatusNotFound)
        return
    }
    json.NewEncoder(w).Encode(droplet)
}

This approach ensures that even if an attacker guesses or enumerates another user’s droplet ID, the request will be rejected because the ID does not appear in the list of droplets accessible to the token.

Node.js (using doctl or the digitalocean npm package)

Vulnerable Express route:

app.get('/internal/droplets/:id', async (req, res) => {
    const { id } = req.params;
    try {
        const droplet = await do.droplets.get(id);
        res.json(droplet);
    } catch (e) {
        res.status(404).send(e.message);
    }
});

Remediated version:

app.get('/internal/droplets/:id', async (req, res) => {
    const { id } = req.params;
    const dropletId = parseInt(id, 10);
    if (isNaN(dropletId)) {
        return res.status(400).send('invalid droplet ID');
    }
    // Fetch the list of droplets accessible to the token
    let authorized = false;
    let page = 1;
    do {
        const { droplets, meta } = await do.droplets.getAll({ page, per_page: 200 });
        for (const d of droplets) {
            if d.id === dropletId {
                authorized = true;
                break;
            }
        }
        if (authorized) break;
        page = meta.links.pages.next || 0;
    } while (page);

    if (!authorized) {
        return res.status(403).send('forbidden');
    }

    try {
        const droplet = await do.droplets.get(dropletId);
        res.json(droplet);
    } catch (e) {
        res.status(404).send(e.message);
    }
});

Both examples illustrate the principle: never trust the identifier alone; always confirm that the acting token is permitted to operate on that object.

Additional hardening tips specific to DigitalOcean:

• Use project-scoped tokens or team-scoped tokens when possible, limiting the blast radius of a compromised token.
• Leverage DigitalOcean’s tags feature to embed project or environment information and validate that the tag matches the expected context.
• Enable audit logging via DigitalOcean’s monitoring tools to detect anomalous access patterns (e.g., a spike in 403 responses from a single IP).
• When building internal tooling, prefer using the DigitalOcean API’s /v2/account endpoint to verify the token’s associated UUID and then cross‑reference that with internal ownership maps.

By applying these checks, developers eliminate the BOLA/IDOR vector while still benefiting from the convenience of the DigitalOcean API. middleBrick will continue to report any remaining instances, allowing teams to track remediation progress over time.