OWASP Top 10 и прикладной слой and the application layer

Атаки на веб/APIWeb/API attacks

Уязвимости прикладного уровня, с которыми реально сталкивается любой, кто пишет API: инъекции, подделка запросов, небезопасная десериализация, логические дыры авторизации. По классификации OWASP Top 10 плюс то, что чаще всего встречается в gRPC/REST API конкретно. Каркас: 9 карточек, страницы ещё не написаны.Application-layer vulnerabilities anyone writing an API actually runs into: injection, request forgery, insecure deserialization, authorization logic holes. Follows the OWASP Top 10 classification plus what shows up most often in gRPC/REST APIs specifically. Skeleton: 9 cards, pages not yet written.

ИнъекцииInjection

непроверенный ввод как исполняемый кодunvalidated input as executable code

SQL InjectionКонкатенация ввода в запрос вместо параметризации, blind/time-based варианты, почему ORM не гарантия защиты сама по себе.Concatenating input into a query instead of parameterizing it, blind/time-based variants, why an ORM alone isn't a guarantee of safety.interview XSSStored/reflected/DOM-based XSS, почему экранирование вывода — не то же самое, что валидация ввода, Content Security Policy как защита второго рубежа.Stored/reflected/DOM-based XSS, why output escaping isn't the same as input validation, Content Security Policy as a second line of defense. Небезопасная десериализацияInsecure deserializationКак десериализация недоверенных данных превращается в удалённое выполнение кода — пример проблемы pickle в Python, ysoserial-класс атак в Java.How deserializing untrusted data turns into remote code execution — Python's pickle problem, the ysoserial class of attacks in Java.

Подделка запросовRequest forgery

жертва или сервер действуют от чужого имениthe victim or server acts on someone else's behalf

CSRFБраузер жертвы отправляет авторизованный запрос без её ведома, SameSite cookies и CSRF-токены как защита.The victim's browser sends an authorized request without their knowledge, SameSite cookies and CSRF tokens as defense. SSRFСервер делает запрос по адресу, который контролирует атакующий — доступ к внутренним сервисам, metadata-эндпоинтам облака (169.254.169.254).The server makes a request to an address the attacker controls — reaching internal services, cloud metadata endpoints (169.254.169.254).interview

Логика авторизацииAuthorization logic

валидный запрос, неправильные праваa valid request, wrong permissions

IDORInsecure Direct Object Reference — доступ к чужим данным через предсказуемый идентификатор без проверки прав на объект.Insecure Direct Object Reference — reaching someone else's data via a predictable identifier with no per-object permission check. Broken AuthenticationСлабые сессии, предсказуемые токены, отсутствие rate limiting на логине, небезопасное хранение паролей.Weak sessions, predictable tokens, no login rate limiting, insecure password storage.

Зависимости и конфигурацияDependencies & configuration

уязвимость приходит извне кодаthe vulnerability comes from outside your own code

Уязвимые зависимостиVulnerable dependenciesCVE в сторонних библиотеках, SBOM и сканирование зависимостей, почему «мы не трогали этот код» не защита.CVEs in third-party libraries, SBOMs and dependency scanning, why "we didn't touch that code" isn't a defense. Security misconfigurationSecurity misconfigurationДефолтные учётки, избыточные права по умолчанию, подробные сообщения об ошибках в проде, открытые debug-эндпоинты.Default credentials, overly permissive defaults, verbose error messages in production, exposed debug endpoints.

статусstatus

Это каркас: 9 карточки зафиксированы, страницы ещё не написаны. Классификация ориентируется на OWASP Top 10, но не копирует её один в один — состав подобран под то, что действительно всплывает при разработке API.This is a skeleton: 9 cards are locked in, pages not yet written. The classification takes its cue from the OWASP Top 10 but isn't a straight copy — the selection is tuned toward what actually comes up building APIs.