Проверка безопасности перед оплатой — есть ли у нас свой чек-лист по безопасности сайта, который мы можем применить сами?

Откройте консоль разработчика в браузере и посмотрите вкладку безопасности, а также просканируйте сайт бесплатными инструментами анализа заголовков. Добавить недостающие заголовки безопасности из отчёта в конфигурацию сервера займёт всего 30 минут и сразу отсеет половину отчёта.

В отчёте о пентесте, за который мы заплатили 3 200 фунтов в прошлом году, было 11 находок. 7 из них — недостающие заголовки на сервере и открытый листинг каталогов. Если бы мы сделали эти проверки заранее, мы могли бы заставить аудиторскую фирму искать логические ошибки в самом потоке оплаты приложения.

Обязательно кастомизируйте страницы ошибок. Если ваш сервер или софт при ошибке 500 выводит на экран стек вызовов (stack trace) или версию базы данных, вы даёте атакующему карту. В продакшене отключите все детали ошибок и показывайте только общий код ошибки.

Добавьте в свой чек-лист ещё вот что: 1) Активность CSRF-токенов в формах бронирования. 2) Чтобы в файле robots.txt не раскрывались скрытые панели или резервные каталоги. 3) Проверка забытых на сервере конфиденциальных файлов конфигурации вроде .zip, .sql или .env.

Своим чек-листом вы обеспечите базовую гигиену, но не думайте, что это замена профессиональному тесту. Уязвимости бизнес-логики (например, превышение прав, когда меняешь id чужого бронирования и видишь его запись) не появятся ни в одном автоматическом списке. Составьте свой чек-лист, но не откладывайте аудит полностью.

ещё советую проверить систему бэкапов. в общем безопасность — это не только момент атаки; если что-то пойдёт не так, можете ли вы вернуться к чистым данным часовой давности и лежит ли этот бэкап на другом изолированном сервере — это очень критично.

Поскольку вы работаете в Великобритании, защита пользовательских данных создаёт прямую юридическую ответственность. Если вы оформите базовые проверки в виде внутреннего отчёта по безопасности с датой, это докажет добросовестность и проактивный подход вашей организации при возможном аудите безопасности данных.

Не пугайтесь, эти проверки можно сделать за день. Хотя бы исправьте базовые настройки и идите к фирме с этим; когда вы скажете «мы сделали базовые проверки, от вас нам нужен только глубокий анализ бизнес-логики», они могут даже снизить цену предложения.

Я тоже так считаю. Любой пункт, не зафиксированный письменно, в будущем обе стороны будут помнить по-разному.

Исправьте, если я ошибаюсь.

слежу за темой потом корче решения работающие в малом масштабе, рушатся при росте я узнал это слишком поздно.

две недели ведения заметок дают лчший результат чем шестимесячные прогнозы. если напишете результат здесь, это поможет и другим.

На это стоит обратить внимание. Если делаете впервые начните с малого масштабирование потом.

Пытаться сделать это в одиночку — самый дорогой путь. Удачи.

Ответ выше точно передал суть вопроса. Пытаться сделать это в одиночку — самый дорогой путь.

Если путь уведомления длинный, уведомление не приходит; а не пришедшее уведомление — это поздно обнаруженный инцидент. Я бы пошел этим путем.

Эта тема в архиве.

не упустите: Время обнаруженя проблемы напрямую определяет ее стоимость.

конечно если ваша ситуация отличается, всё меняется.

У меня будет вопрос, не хочу уходить от темы, но... При принятии решений записывайте и худший сценарий, а не только лучший.

Исправьте, если я ошибаюсь.

в прошлом году мы столкнулись практически с тем же самым... в общем безопасность не бывает абсолютной; цель — сделать атаку нецелесообразной.

интересно, есть ли те кто деает иначе.

Попробую.

Появились три разных мнения они дополняют друг друга. Если разрешение и объем тестирования не зафиксированы письменно, тест не начинать.

Если напишете результат здесь, это поможет и другим.