Recheck Authorization at the Point of Use

Sat, 05 Sep 2026 00:00:00 +0700

An application can perform a correct authorization check and still allow an action that should no longer be permitted. The problem appears when the application checks authority, waits or performs other work, and only later changes protected state. During that gap, the facts that justified the decision can change.

For example, a worker may confirm that a user can modify a project, queue the requested change, and apply it several seconds later. If the user’s project access is revoked before the worker runs, using the earlier decision can let revoked authority survive longer than intended.

Make Security-Sensitive State Changes Atomic

Fri, 04 Sep 2026 00:00:00 +0700

Security checks can be individually correct and still fail when two requests run at the same time. A request checks that a recovery code is unused, a withdrawal is within a limit, or an approval is still pending. Before it records the state change, another request performs the same check against the same old state. Both requests then proceed even though the rule was meant to allow only one.

This is a race condition: correctness depends on the relative timing of concurrent operations. A common form is a time-of-check to time-of-use problem, often shortened to TOCTOU, where the fact established by a check can become false before the protected action uses it.

Race Conditions on Nalar

Recheck Authorization at the Point of Use

Make Security-Sensitive State Changes Atomic