Заметил, что сколько ни клепай новых фреймворков и библиотек, старые добрые дыры типа XSS и SQL-инъекций всё ещё регулярно всплывают в реальных проектах. Казалось бы, за последние годы появился целый ворох средств защиты: Content Security Policy, подготовленные запросы, современные бэкенд-фреймворки с автоматической эскейпингом данных. Но на практике почему-то почти на каждом более-менее крупном сайте можно найти что-то из этого набора — и даже не из-за суперсложных технологий, а из-за банальных просчётов валидации и неправильного понимания, кто отвечает за безопасность.

Сам лично видел, как в одном проекте по API забыли проверить типы данных на входе — казалось бы, мелочь, а напрочь убила всю логическую защиту на уровне бизнес-правил. А в другом случае — рутинный XSS через форму обратной связи, который проехал на прод из-за неполного покрытия автотестами. У меня складывается ощущение, что проблема не только в технологиях, а в том, что люди порой воспринимают безопасность как дополнительную нагрузку, а не как неотъемлемую часть разработки.

Интересно, что многие продолжают гоняться за новыми уязвимостями и техниками атак, забывая про базовый фундамент — грамотное проектирование и составление тестов. Например, те же BOLA или SSRF звучат фантастически круто, но порой забывается, что при должной простоте валидации и разграничении прав такие баги либо совсем не возникнут, либо их будет очень сложно реализовать. Это нормальный спорный момент — стоит ли тратить огромные ресурсы на защиту от всех современных атак, если базовая гигиена кода зачастую хромает?

Как думаете, где сейчас узкое место: в инструментах, в подходах к разработке или в культуре безопасности среди команд? Может, просто не хватает реального примера, когда именно благодаря исправлению базовых моментов проект реально стал устойчивее? Поделитесь, кто что думает!