Насколько сложно защитить веб-приложение от основных видов атак?
Зависит от того, что за конкретное приложение и кому может понадобиться его ломать, сколько он готов будет вложить времени и денег. Ответ на это определит возможный вектор атак и соответствующие меры и стоимость защиты.
Насчет ddos вы, видимо, не совсем понимаете, что это такое. Если у сервера узкий канал, то проверки ip внутри приложения не спасут вообще никак. Если же канал широкий и у вас достаточное количество мощностей, а само приложение (бэк) хорошо оптимизировано, то можно спокойно жить под ddos, не беспокоясь об этом. Кроме того, есть облака, которым (как раз по этой причине) пофиг на ddos. В общем, это сложная тема, в пару слов не уложусь.
В общем, вы сейчас пытаетесь изобрести универсальный рецепт приготовления обеда из абстрактных ингредиентов в вакууме. Выбирайте, либо вы тратите кучу времени на чтение кучи книг и изучение темы ИБ в целом, либо вы решаете конкретную задачу и изобретаете что-то своё или берёте от ИБ то немногое, что понадобится в рамках этой задачи. А просто перечислить в 300 символов, что хорошо и что плохо, - не получится.
Все данные, которые поступают от клиента, нужно проверять на валидность, и во многих случаях экранировать;
Ваш КЭП. Только что касается экранирования тут все куда сложнее чем тебе кажетсяURL, вводимый пользователем должен сверяться с белым списком;
Ну, неплохая идея, если бы белый список не был бы такой что вы его никогда не составите. Как и черный список. Скорее тут надо вводить дополнительные системы мониторинга и модерацииНе должно быть url-адресов, которые без подтверждения пользователя выполняют какие-то действия на сайте;
Ну не делай ихPOST предпочтительней GET;
Простите, поперхнулся. А еще есть десяток других типов HTTP запросов - что про них скажешь? Сначала узнай зачем они и как с ними что работает. К безопасности не относится никакПри возможности, стоит включить CSP;
Можно, но это уже так, с боку бантикВсе важные данные нужно хешировать (последним поколением хеш функций);
Особенно нравится все и последним поколением. Идея в примерно отдаленно верном направлении, а формулировка все портит и говорит "пойди почитай матчасть про хэширование"Необходимо использовать https протокол (тем более, СЕО...);
Хорошая идея, но, только не так. Читай про SSL/TLSВ куки не следует хранить конфиденциальную информацию, кража которой могла бы навредить;
Есть целый блок ИБ про Sensitive Information. Нужно понимать что это и понять что куки это всего одно из миллиона местПри регистрации пользователя требовать некоторого уровня надежности пароля;
Лесом. Эта практика умирает как и ротация паролей - даже Microsoft отказывается от таких практик в Active Directory. В области Web так вообще пароли редкость уже для сервисов ибо есть социальные логины, SSO, мультифактор и много еще чегоПри нескольких неудачных попытках входа с одним и тем же логином, или на одном ip, нужно добавить паузу и/или капчу, в определенных случаях блокировать ip;
Можно, но это опять - с боку бантикЧтобы в некоторой степени защититься от DDoS атак, неплохо бы написать скрипт, который в случае превышения определенного лимита connect/time с одного ip, блокировал бы этот ip.
Мимо. Просто мимо. Читать матчасть
По сути про ИБ тут ничего от слова совсем. По крайней мере кроме валидации данных и SSL ничего действительно серьезного не затронуто. Я бы сказал что тут от ИБ и сотой доли процента нет