Time Of Check Time Of Use in Actix with Cockroachdb

Time Of Check Time Of Use (TOCTOU) occurs when the state used to make a security decision changes between the check and the use of that decision. In an Actix application using CockroachDB, this commonly appears in authorization flows where permissions are verified with one query and later acted upon with another, without holding or re-verifying the relevant state.

Consider an endpoint that first checks a user’s role or ownership (e.g., "does this user own this document?"), then proceeds to perform a database write. If the check and the use are separate transactions, an attacker can mutate the underlying data between the two operations. With CockroachDB’s serializable isolation, each transaction sees a consistent snapshot; however, if the Actix service uses separate transactions for the check and the use, the snapshot used for the check can be stale by the time the use transaction runs. This enables scenarios such as a user changing their permissions or the resource’s ownership between the check and the use, leading to unauthorized actions despite an apparently valid check.

A concrete pattern in Actix might look like a handler that reads a row to confirm ownership, then updates it in a separate transaction. Because CockroachDB does not lock the row across transactions by default, an attacker who can influence the resource state between the two transactions can exploit the window. For example, a PATCH /documents/{id} endpoint might first run a SELECT to verify the current owner_id matches the authenticated user, then run an UPDATE. If an attacker can change the document’s owner between these two statements (for instance, via another compromised account or a synchronization lag), the UPDATE executes without proper authorization, despite the initial check passing.

Additionally, if the Actix service caches or reuses a permission value across requests (e.g., placing a check result in request-local data and reusing it), the cached value can become invalid if the underlying data changes mid-request processing or across retries. CockroachDB’s strong consistency helps, but it does not prevent TOCTOU when checks and writes are separated by application logic and distinct transactions. This is especially relevant when combined with features like interleaved reads and writes, or when secondary indexes are eventually consistent in observable ways across regions.

Another variant involves optimistic concurrency controls where the check (version/timestamp validation) and the use (write) are intended to be atomic but are implemented as two separate steps due to middleware or service design. An attacker can submit multiple requests to shift state between the validation and the write. Even with CockroachDB’s transaction guarantees, the application must ensure that the decision logic and the write occur within a single transaction or are otherwise tightly coupled to prevent race conditions.

To prevent TOCTOU in Actix with CockroachDB, keep authorization checks and state changes within a single database transaction. Use explicit row-level locking or conditional writes so that the check and the use are atomic. Avoid separate read-then-write patterns unless they are protected by stronger guarantees (e.g., serializable transactions with explicit checks for write skew).

Example: Safe atomic update with conditional WHERE

Instead of reading then writing, encode the permission check as a conditional update. This ensures the update only succeeds if the current state matches expectations, and it executes atomically in one transaction.

use cockroachdb::Client;
use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct Document {
    id: i32,
    owner_id: i32,
    content: String,
    version: i64,
}

// Atomic update in a single transaction: only update if owner_id matches expected.
async fn update_document_if_owner(
    client: &Client,
    doc_id: i32,
    expected_owner_id: i32,
    new_content: String,
) -> Result<(), Box> {
    let tx = client.transaction().await?;
    // Conditional write: the WHERE clause encodes the authorization check.
    tx.execute(
        "UPDATE documents SET content = $1, version = version + 1 WHERE id = $2 AND owner_id = $3",
        &[&new_content, &doc_id, &expected_owner_id],
    ).await?;
    // Optionally inspect rows_affected to enforce that the row existed and matched.
    tx.commit().await?;
    Ok(())
}

Example: SELECT FOR UPDATE within a transaction

If you must read before writing, use SELECT … FOR UPDATE (or equivalent) within the same transaction to lock the row for the duration of the transaction. In CockroachDB, this prevents concurrent modifications that could change ownership between the check and the use.

use cockroachdb::Client;
use tokio_postgres::Row;

async fn safe_update_with_lock(
    client: &Client,
    doc_id: i32,
    user_id: i32,
    new_content: String,
) -> Result<(), Box> {
    let tx = client.transaction().await?;
    // Lock the row for update within this transaction.
    let row: Row = tx.query_one(
        "SELECT id, owner_id FROM documents WHERE id = $1 FOR UPDATE",
        &[&doc_id],
    ).await?;
    let owner_id: i32 = row.get("owner_id");
    if owner_id != user_id {
        return Err("unauthorized".into());
    }
    // Proceed with update while the row is locked.
    tx.execute(
        "UPDATE documents SET content = $1 WHERE id = $2",
        &[&new_content, &doc_id],
    ).await?;
    tx.commit().await?;
    Ok(())
}

Leverage CockroachDB serializable isolation with explicit retry logic

Run the authorization check and the state change in a single transaction and handle serialization errors by retrying. This avoids long-held locks while ensuring the check and use are consistent.

use cockroachdb::Client;
use std::time::Duration;
use tokio::time::sleep;

async fn update_with_retry(client: &Client, doc_id: i32, user_id: i32, new_content: String) -> Result<(), Box> {
    let mut retries = 0;
    loop {
        let tx = client.transaction().await?;
        let row: Row = match tx.query_opt("SELECT id, owner_id FROM documents WHERE id = $1", &[&doc_id]).await? {
            Some(r) => r,
            None => return Err("not found".into()),
        };
        if row.get::<_, i32>("owner_id") != user_id {
            return Err("unauthorized".into());
        }
        tx.execute("UPDATE documents SET content = $1 WHERE id = $2", &[&new_content, &doc_id]).await?;
        match tx.commit().await {
            Ok(_) => return Ok(()),
            Err(e) if is_serializable_retryable(&e) => {
                retries += 1;
                if retries > 5 {
                    return Err("too many retries".into());
                }
                sleep(Duration::from_millis(50)).await;
                continue;
            }
            Err(e) => return Err(e.into()),
        }
    }
}

In Actix, prefer extractor patterns that bind authorization to the transaction scope and avoid caching decision results across awaits. When using the MCP Server or CLI to scan your API, ensure that generated tests or mocks do not encourage read-then-write patterns; instead, validate that authorization logic is atomic. These practices reduce the risk window and align with OWASP API Top 10 A01:2023 broken object level authorization, which tools like middleBrick can help surface through its BOLA/IDOR checks when scanning endpoints built on Actix and CockroachDB integrations.