Пока все пугают XSS и SQLi, самая неприятная дыра часто сидит в банальной спешке сервера.

Пока все пугают XSS и SQLi, самая неприятная дыра часто сидит в банальной спешке сервера.

Race Condition — это когда приложение не успевает договориться само с собой. Два запроса прилетают почти одновременно, лезут в одни и те же данные — и начинается хаос: лимит обходится, деньги списываются дважды, чужой аккаунт внезапно становится «вашим». ⚠️

И вот что бесит: такие баги редко выглядят как «критическая уязвимость» на старте. Снаружи — обычный workflow. Внутри — отсутствие синхронизации.

У race condition обычно три лица:
1) time-of-check vs time-of-use — проверили, а использовали уже в другой реальности;
2) double spend — когда операция проходит дважды;
3) limit bypass — когда ограничения существуют только на бумаге.

Если ищешь их вручную, смотри не на код “вообще”, а на места, где есть:
проверка баланса,
смена статуса,
создание заказа,
редирект на оплату,
любая операция “один раз”.

Там и живёт баг, который любит параллельность. Проверяю на конверсию: если в системе есть “успеть первым”, уязвимость уже рядом.