API/BOLA: почему две роли важнее ещё одного сканера
IDOR/BOLA редко находится красивым payload. Чаще он проявляется там, где у API есть object id, две роли, разные владельцы данных и слабая проверка на уровне объекта.
читать разбор →// pentest / web / api / evidence
Вертикаль про реальный web/API-пентест, где важны не только surface и payload, но и authenticated coverage, role/state matrix, lifecycle объекта, session trust, evidence packs и честные coverage gaps. Это уже не сканер, а проверяемая методология.
inventory -> role/state coverage -> evidence pack -> fix -> retest
// updated
// focused stream
IDOR/BOLA редко находится красивым payload. Чаще он проявляется там, где у API есть object id, две роли, разные владельцы данных и слабая проверка на уровне объекта.
читать разбор →Самая неприятная API-проблема не всегда выглядит как уязвимость. Часто это просто несоответствие между документацией, релизом и реальным трафиком: старый endpoint живёт, новый не описан, а ограничения доступа различаются.
читать разбор →Passkeys отлично убирают часть password risk, но они не решают автоматически вопросы session fixation, recovery bypass, weak step-up и долгоживущих cookies. После WebAuthn всё равно остаётся инженерия доверия.
читать разбор →Большая часть настоящей ценности API-пентеста появляется только после аутентификации. Именно там находятся object boundaries, approval flows, hidden exports, admin-adjacent methods и различия между тем, что видно владельцу, оператору и аудитору.
читать разбор →Сильный web/API-отчёт отличается не числом находок, а качеством доказательства. Когда finding можно воспроизвести по request/response trace, curl, hash, role/state notes и критерию ретеста, спор о его реальности быстро заканчивается.
читать разбор →// working logic
Хороший web/API-аудит движется по цепочке: inventory, roles, state, differential evidence, remediation, retest. Если один из этапов пропущен, finding теряет инженерную силу.
inventory -> role/state coverage -> evidence pack -> fix -> retest
// related