Time Of Check Time Of Use in Fastapi with Cockroachdb

Time Of Check Time Of Use (TOCTOU) occurs when the outcome of a security-relevant check depends on timing between verification and use. In a Fastapi application using Cockroachdb, this commonly arises when permissions or existence checks are performed in one request or transaction and the subsequent operation is executed in a separate transaction or request without re-verifying the same context.

Consider an endpoint that first checks whether a user has a specific role in a Cockroachdb table, then performs a data operation based on that role. If the role is modified or the row is deleted between the check and the use, the authorization decision becomes invalid. Because Cockroachdb is strongly consistent within a transaction, a single transaction that both checks and acts avoids this gap. However, if Fastapi executes multiple database calls across separate transactions or sessions, the window for state change remains. Attackers can exploit this by altering permissions or row state after the check but before the use, leading to unauthorized access or privilege escalation.

An example pattern that introduces TOCTOU:

from fastapi import Depends, HTTPException, status
from sqlalchemy.orm import Session
from myapp.models import User, Permission
from myapp.db import get_session

def get_user_permission(user_id: int, permission: str, db: Session = Depends(get_session)):
    # Check
    record = db.query(Permission).filter(Permission.user_id == user_id, Permission.name == permission).first()
    if not record:
        raise HTTPException(status_code=status.HTTP_403_FORBIDDEN, detail="Permission denied")
    return record

@app.post("/data/{record_id}")
def update_record(record_id: int, user_id: int, db: Session = Depends(get_session)):
    # TOCTOU: permission checked in one call, used in another without re-validation inside a transaction
    get_user_permission(user_id, "modify_data", db)
    # Use: perform update in a separate transaction/session
    record = db.query(DataRecord).get(record_id)
    if not record:
        raise HTTPException(status_code=404, detail="Record not found")
    record.value = "modified"
    db.commit()
    return {"status": "ok"}

In the above, the permission check and the update run in different logical operations. An attacker could revoke or modify the permission between the check and the commit if the application does not enforce a single, atomic authorization decision within a Cockroachdb transaction. This is especially relevant when Fastapi reuses session scopes or connection pools in ways that do not align with the intended transactional boundaries.

OpenAPI/Swagger spec analysis helps surface these risks when endpoints describe multiple security- and data-dependent steps without indicating they should be co-located in a single transaction. middleBrick scans can identify such patterns by correlating authentication, BOLA/IDOR, and authorization checks with the corresponding database interactions in the spec and runtime behavior, flagging missing transactional integrity.

To eliminate TOCTOU in Fastapi with Cockroachdb, perform the check and the use within the same transaction so that the state cannot change between them. Cockroachdb’s serializable isolation level helps ensure that the transaction either sees a consistent snapshot or aborts if a conflict occurs, which is ideal for authorization-sensitive operations.

Remediation pattern: combine authorization check and data modification in one database transaction using SQLAlchemy with explicit transaction control:

from fastapi import Depends, HTTPException, status
from sqlalchemy.orm import Session
from sqlalchemy import select, update
from myapp.models import Permission, DataRecord
from myapp.db import get_session

def update_record_safe(record_id: int, user_id: int, db: Session = Depends(get_session)):
    try:
        # Begin explicit transaction
        with db.begin():
            # Check and use within the same transaction
            stmt = select(Permission).filter_by(user_id=user_id, name="modify_data")
            perm = db.execute(stmt).scalar_one_or_none()
            if not perm:
                raise HTTPException(status_code=status.HTTP_403_FORBIDDEN, detail="Permission denied")
            # Use within same transaction
            stmt = update(DataRecord).where(DataRecord.id == record_id).values(value="modified").execution_options(synchronize_session="fetch")
            result = db.execute(stmt)
            if result.rowcount == 0:
                raise HTTPException(status_code=404, detail="Record not found or not updatable")
        # Transaction commits only if both check and use succeed
        return {"status": "ok"}
    except Exception:
        db.rollback()
        raise

This pattern ensures that the permission state is locked (or validated) for the duration of the transaction. If another transaction modifies or revokes the permission, Cockroachdb’s serializable isolation will cause a retryable conflict, which your error handling should catch and surface appropriately to the client.

Additionally, prefer dependency injection that binds the session to the request scope tightly and avoid long-lived sessions that increase the window for state divergence. When integrating with middleware or background tasks, ensure that background work does not rely on stale authorization checks performed earlier in the request lifecycle.

middleBrick can support this remediation approach by scanning your OpenAPI spec and runtime to detect endpoints where authorization checks and data operations are split across multiple calls or transactions, mapping findings to frameworks such as OWASP API Top 10 and SOC2, and providing prioritized remediation guidance without claiming to fix or block traffic.