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


Наиболее распространённые риски безопасности на e-commerce платформах


1. Необновлённая система и плагины

Риск: использование устаревших версий платформы, плагинов или серверного ПО содержит известные уязвимости (SQL-инъекции, XSS, RCE).

Защита: регулярное обновление платформы, плагинов и серверного ПО.

Последствия: злоумышленники могут захватить контроль над магазином и украсть данные клиентов и платежные данные.


2. Слабые пароли и недостаточная аутентификация

Риск: взлом аккаунтов администраторов или клиентов с помощью brute-force или credential stuffing.

Защита: сложные пароли, двухфакторная аутентификация (2FA), ограничение количества попыток входа.

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


3. Небезопасные плагины и модули

Риск: сторонние расширения часто содержат уязвимости или вредоносный код.

Защита: использовать только плагины от надёжных разработчиков; по возможности проверять код.

Последствия: внедрение backdoor, вредоносные инъекции, утечка данных.


4. Brute-force и DoS-атаки

Риск: автоматизированные атаки могут заблокировать магазин или взломать аккаунты.

Защита: WAF (Web Application Firewall), ограничение попыток входа, CDN с защитой от DoS.

Последствия: недоступность магазина — потеря дохода и доверия клиентов.


5. Недостаточная безопасность сервера

Риск: неправильная конфигурация хостинга (открытые порты, слабые настройки).

Защита: безопасный хостинг, файрвол, регулярные аудиты сервера.

Последствия: злоумышленники получают прямой доступ к БД или файловой системе, полный компромисс магазина.


6. Утечка платёжных данных

Риск: потеря данных карт и других способов оплаты (несоответствие PCI-DSS).

Защита: использовать доверенные платёжные шлюзы (Swedbank, SEB, Stripe, PayPal), SSL/TLS, не хранить данные карт на своём сервере.

Последствия: кража финансовых данных, репутационный ущерб, юридические последствия (например, штрафы GDPR, PCI-DSS).


7. Социальная инженерия и фишинг

Риск: администраторы или клиенты могут быть обмануты и раскрыть пароли через e-mail или поддельные ссылки.

Защита: обучение персонала и клиентов, фильтрация e-mail, 2FA.

Последствия: несанкционированный доступ, захват аккаунтов, кража данных.


8. Недостаточное шифрование данных и резервное копирование

Риск: данные могут быть перехвачены или потеряны в результате атаки или сбоя системы.

Защита: HTTPS на всем сайте, шифрование БД, регулярные внешние бэкапы.

Последствия: утечка данных, риск для бизнес-континуитета, невозможность восстановиться после кибератаки.


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


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


Защита от XSS-атак

Межсайтовый скриптинг (XSS) — это уязвимость безопасности, которая чаще всего затрагивает веб-приложения. Она позволяет кому-либо внедрить вредоносный код (обычно JavaScript) в витрину магазина. Это не влияет напрямую на сам сайт/магазин, но затрагивает конечного пользователя, который его посещает. Это может привести к таким вредоносным последствиям, как кража сессионных куки, подделка личности пользователя, выполнение несанкционированных действий от имени пользователя и доступ к конфиденциальным данным.


Давайте посмотрим, как четыре популярные платформы справляются с этой проблемой.


OpenCart 4 — очень хорошо!

OpenCart 4 использует систему шаблонов Twig, которая автоматически экранирует вывод. Проще говоря: если кто-то пытается «вставить» нежелательный код в форму или комментарий, система преобразует его в безвредный текст.


Также стоит установить заголовки CSP на сервере — благодаря им магазин сообщает браузеру, откуда он может загружать скрипты, а откуда — нет. На практике это похоже на щит, который говорит: «Эй, не делай ничего, что я не одобрил!».


Оценка: 4/5. Защита по умолчанию + возможность дальнейшего усиления без серьезных изменений.


Magento (Adobe Commerce) – надежная защита, но…

Magento имеет надежные встроенные механизмы: все пользовательские данные проверяются и «очищаются» перед отображением. Для этого используются такие функции, как escapeHtml.


Но есть один нюанс… многое зависит от расширений. Если вы добавите модуль, который не соответствует правилам безопасности Magento, XSS может проникнуть в систему, несмотря на надежный ядро. [1] Adobe (владелец Magento) многое делает для контроля этого, но не все можно предсказать.


Оценка: 4/5. Теоретически надежно, но нужно быть осторожным с тем, что вы устанавливаете.


PrestaShop – здесь рекомендуется осторожность

PrestaShop по умолчанию не предлагает такой сильной защиты. Безопасность в основном зависит от обновления системы и использования дополнительных инструментов (таких как WAF или заголовки безопасности).


История показывает, что XSS довольно распространен в PrestaShop. Были случаи (например, CVE-2024-34716, PrestaShop 8.1.0–8.1.5), когда такая уязвимость могла даже привести к удаленному захвату магазина. [2] Эти ошибки, конечно, исправляются, но если вы не применяете обновления, риск остается высоким.


Оценка: 3/5. Требует дополнительной работы и постоянных обновлений. Для нетехнических пользователей это может быть слишком рискованно.


WooCommerce – зависит от того, что вы устанавливаете…

WooCommerce, как расширение WordPress, использует его механизмы безопасности, которые являются довольно эффективными. WP предоставляет такие функции, как esc_html(), esc_url() и wp_kses(), чтобы гарантировать, что вредоносный JavaScript не будет вставлен в страницу.


Это немного похоже на проверку продуктов на кассе — все, что попадает на сайт, фильтруется, а нежелательный код отклоняется.


Проблема начинается, когда вы устанавливаете плагин из неизвестного источника или плагин, который устарел на два года. И это не просто теория. Согласно отчету за 2024 год, 96% проблем безопасности WordPress вызваны плагинами. [3]


Таким образом, WooCommerce может быть безопасным, но это в значительной степени зависит от вас: регулярные обновления, продуманный выбор плагинов/тем. Также установите заголовки безопасности (такие как Content-Security-Policy) для усиления защиты от XSS.


Оценка: 2/5. Вы можете защитить себя, но для этого требуется понимание и системный подход. Новичкам легко что-то упустить.


Защита от атак CSRF

CSRF (Cross-Site Request Forgery) — еще один вид атак, который может стать серьезной проблемой для владельцев интернет-магазинов. Вкратце: кто-то выдаёт себя за авторизованного пользователя и от его имени выполняет действия, которые тот сам не планировал — например, изменяет адрес доставки, отменяет заказ или, в случае администратора, удаляет товары или меняет пароль.


Давайте посмотрим, как популярные платформы справляются с этой проблемой:


Magento — безопасная, но...

Magento использует «ключи форм» — уникальные «штампы», добавляемые к формам и запросам. Сервер проверяет, соответствует ли ключ текущей сессии — если нет, запрос отклоняется. Просто и эффективно.


Но обратите внимание: технически Magento позволяет обойти эту защиту, например, в пользовательских интеграциях. Здесь часто возникают проблемы — кто-то пишет плагин, который обходит защиту, и CSRF проскальзывает. [4] Так что в Magento многое зависит от разработчика.


Оценка: 4/5. Хорошо защищен, если кто-то не ослабляет его намеренно.


PrestaShop – когда-то слабый, теперь лучше, но риски остаются

PrestaShop использует токены безопасности (коды, которые помогают проверить легитимность доступа). В прошлом было много проблем – например, в 2023 году уязвимость [5] позволяла повторно использовать старые токены сессии для доступа к панели администратора. Другими словами, однажды получив доступ, вы могли продолжать получать его, когда не должны были. Эта ошибка была исправлена, но некоторое недоверие осталось.


Даже сейчас пользователи часто сталкиваются с сообщением «CSRF token invalid» (Недействительный токен CSRF). Это означает, что токен не распознается и доступ запрещен. Проблема возникает нерегулярно — чаще всего с определенными модулями или у некоторых хостинг-провайдеров. К сожалению, некоторые владельцы магазинов предпочитают полностью отключить защиту, а не устранять основную проблему, что снижает уровень безопасности.


Оценка: 3/5. Система работает, но она уязвима — легко сломать или отключить важный элемент управления. Обращайтесь с ней осторожно.


OpenCart 4 — легкая защита, но в правильном направлении

OpenCart использует токены, добавляемые в URL (например, user_token). Вы можете рассматривать это как своего рода подпись сеанса, подтверждающую, что запрос поступил от реального пользователя. Этот подход в основном используется в панели администратора для защиты от базовых атак.


Однако: комплексная, унифицированная защита присутствует не везде — например, на стороне клиента. Действия администратора в значительной степени защищены, но если магазин обширный и имеет много функций, мы рекомендуем самостоятельно добавить дополнительные уровни безопасности.


Оценка: 4/5. Подходит для повседневного использования, но не является полностью комплексным.


WooCommerce – отличные инструменты, но все зависит от вас

WooCommerce использует одноразовые коды WordPress, которые присваиваются конкретному действию пользователя. Их можно добавлять в формы, кнопки и даже ссылки. Это очень полезный механизм, который при правильном использовании обеспечивает хорошую защиту.


Но опять же — плагины. Эта отличная защита эффективна только в том случае, если ее используют грамотно. Более 90% проблем с безопасностью WordPress связаны с плагинами, поэтому несложно догадаться, где находится слабое место. Если плагины низкого качества или не обновляются регулярно, защита становится уязвимой.


Оценка: 3/5. Сам механизм отличный, но безопасность во многом зависит от качества плагинов и их обслуживания.


Защита от SQL-инъекций

SQL-инъекции используют слабые места системы. Это по-прежнему один из самых распространенных методов взлома. Злоумышленник, знающий об уязвимости, может вставлять команды (SQL-код) туда, где им не место, и получать доступ к базе данных магазина.


Результат? Злоумышленник может получить доступ к базе данных, в которой хранится все, что не должно попасть в чужие руки: данные клиентов, заказы, пароли и много другой конфиденциальной информации.


SQL-инъекции считаются одними из самых опасных атак — это как открыть дверь изнутри, если безопасность настроена неправильно.


Magento — надежная защита от SQLi, с одним «но»

Защита Magento от SQL находится на высоком уровне. Она использует подготовленные заявления — безопасный способ передачи данных в SQL-запросах. Проще говоря, данные и команды отправляются отдельно, поэтому введенные пользователем данные не могут случайно (или злонамеренно) изменить смысл запроса.


Кроме того, Magento использует собственный ORM («переводчик» между кодом PHP и базой данных), который автоматически делает запросы более безопасными.


Однако есть один ключевой риск: многие SQL-атаки в среде Magento происходят из-за плохо написанных плагинов или пользовательских модификаций. [6] Другими словами, ядро очень безопасно, но как только вы устанавливаете некачественные расширения, безопасность снижается.


Оценка: 4/5. Прочная основа, но будьте осторожны с дополнениями.


PrestaShop – исторические риски SQLi

PrestaShop также использует подготовленные запросы, но не всегда и не везде. Были обнаружены серьезные уязвимости SQLi, в том числе такие, которые позволяли похищать данные платежных карт.


Были случаи, когда популярный модуль имел настолько серьезную уязвимость, что удаленный злоумышленник мог захватить контроль над магазином. [7] А поскольку PrestaShop в значительной степени полагается на внешние модули, риск особенно высок.


Поэтому, в дополнение к регулярным обновлениям, рекомендуется использовать межсетевой экран веб-приложений (WAF) для блокирования вредоносных запросов до того, как они достигнут магазина.


Оценка: 3/5. Базовая защита существует, но зависимость от модулей значительно увеличивает риск.


OpenCart 4 — безопасность зависит от разработчика

OpenCart 4 поддерживает подготовленные заявления, более безопасный способ передачи данных в базу данных. Но в отличие от некоторых платформ, OpenCart не требует использования ORM — это означает больше свободы для разработчиков, но и больше риска. С опытным разработчиком система безопасна. С начинающим или небрежным программистом могут появиться дыры в безопасности.


С положительной стороны, код OpenCart 4 гораздо более структурирован, чем в предыдущих версиях, и архитектура улучшена. Это способствует безопасности. Но, как обычно, сторонние расширения являются наиболее распространенным слабым местом.


Оценка: 3/5. Безопасность достижима, но в значительной степени зависит от того, как и кем построена система.


WooCommerce – отличные инструменты, рискованная экосистема

WooCommerce основан на WordPress, где глобальный объект $wpdb и $wpdb->prepare() обеспечивают защиту. При правильном использовании они гарантируют надежную защиту.


Проблема в том, что многие плагины и темы не используют их или используют неправильно. Таким образом, мы возвращаемся к старой проблеме: отличная платформа с рискованной экосистемой плагинов.


Также стоит использовать WAF и проводить аудит кода, особенно для магазинов с высоким трафиком.


Оценка: 2/5. Механизм надежный, но безопасность зависит от качества плагинов и регулярного обслуживания.


Безопасное хранение паролей – что скрывается за экраном?

Мы рассмотрели XSS, CSRF и SQLi; теперь пришло время для того, что затрагивает каждого пользователя: пароли.


Речь идет не о том, где клиент записывает свой пароль (на бумаге или в браузере), а о том, что магазин делает с паролем на стороне сервера.


Помните: если магазин хранит пароли в базе данных в виде «обычного текста», это не магазин – это тикающая бомба.


Итак, давайте посмотрим, какие платформы действительно хэшируют пароли, а какие только делают вид, и где владельцы магазинов могут спать спокойно.


Magento

Magento – образец хранения паролей. Он использует bcrypt – алгоритм, который намеренно медленный… и именно поэтому он хорош. Почему? Чем медленнее процесс взлома, тем сложнее даже суперкомпьютеру угадать пароль.


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


Вы также можете установить разумную длину пароля, цифры, заглавные буквы, специальные символы — все, что вам нужно.


Оценка: 5/5. Отличная защита паролей.


Prestashop

В этом случае ситуация более сложная. Старые версии PrestaShop (до 1.7) хранили пароли с использованием MD5 — сегодня их можно взломать с помощью обычного домашнего ПК и хорошего графического процессора.


Более новые версии, вероятно, перешли на bcrypt, но... неясно, с какой версии, как переносятся старые пароли и безопасно ли пересчитываются пользователи при следующем входе в систему.


Это означает, что, несмотря на улучшения, вам по-прежнему нужно быть осторожными, особенно если магазин был перенесен с очень старых версий.


Оценка: 3/5. Прогресс есть, но есть риски из-за старых данных.


OpenCart 4

Здесь мы наконец видим прогресс. Старые версии (1.x, 2.x) использовали SHA1, который больше не считается безопасным. Но OpenCart 4 (по крайней мере, в GitHub) уже использует password_hash() — встроенную функцию PHP, которая по умолчанию использует bcrypt.


Таким образом, если ваш магазин работает на чистой версии OpenCart 4, есть основания полагать, что пароли хранятся надлежащим образом. Но если вы обновились с более старых версий, убедитесь, что старые пароли будут перегенерированы после следующего входа пользователя. В противном случае слабые старые хэши могут остаться в базе данных.


Оценка: 4/5. Безопасно в новой версии, но следите за путем миграции.


Woocommerce

WooCommerce унаследовал систему паролей WordPress, которая долгое время была безопасной благодаря PHPass.


Лучшая новость: WordPress 6.8 представляет новую, еще более безопасную систему на основе bcrypt + SHA-384. Это делает взлом паролей еще более сложным. Пароли автоматически обновляются до нового стандарта при первом входе в систему после обновления.


Это отличная работа и доказательство того, что экосистема прогрессирует в плане безопасности.


Оценка: 5/5. Безопасная система с четким планом действий.


Изменение пути по умолчанию для администратора — простой способ повышения безопасности

Знаете это чувство, когда вы пытаетесь открыть дверь, но ключ находится не там, где вы ожидали? Так же работают настраиваемые URL-адреса администратора.


Это «безопасность через скрытность». Она не заменяет надежные пароли или защиту от брутфорса, но выполняет полезную функцию — затрудняет ботам доступ к панели администратора.


Вот как это выглядит на разных платформах.


Magento

Magento полностью поддерживает настраиваемые URL-адреса администратора. Вместо стандартного /admin вы можете установить что-то менее очевидное, например /panel-shop-87.


Более того, Magento может добавлять секретные ключи к URL-ссылкам, что означает, что даже если кто-то знает путь, он не сможет войти без ключа. Умно!


Вы можете изменить путь в панели администратора или в env.php.


Оценка: 5/5.


Prestashop

PrestaShop тоже позволяет это сделать. Просто переименуйте папку admin на сервере, например, в zumparizum987. Быстро, просто и работает.


Платформа распознает новое имя и предложит войти через новый путь. Никакой магии, но боты, сканирующие /admin, не смогут войти.


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


Оценка: 4/5.


OpenCart 4

OpenCart получает здесь дополнительные баллы.


Да, вы также можете переименовать папку admin (например, vishum2025), а затем просто настроить пути в config.php и admin/config.php. Так же, как и в PrestaShop: быстро, вручную, но эффективно.


Что еще более важно — по умолчанию OpenCart 4 перемещает каталог хранения за пределы общедоступного корневого каталога веб-сайта. Это означает, что временные данные, резервные копии или файлы журналов находятся не в месте, видимом для всех, а в более безопасной зоне. Очень умный шаг, который снижает риск, если кто-то «заглянет» в вашу структуру папок.


Оценка: 5/5.


Woocommerce

WooCommerce работает на WordPress, и доступ администратора всегда осуществляется через /wp-admin или /wp-login.php. Вы не можете изменить путь по умолчанию без дополнительных плагинов, таких как WPS Hide Login.


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


Оценка: 1/5. Невозможно изменить путь без плагина. С плагином — можно, но риски увеличиваются.


Разделение расширений и модульность — что это значит?

Прежде чем углубляться в технические детали, давайте объясним это простыми словами. Интернет-магазины, как и любое программное обеспечение, со временем растут: вы добавляете функции, интеграции, способы оплаты, слайдеры и многое другое. Как это сделать, не нарушая работу магазина во время обновлений и не создавая хаос в коде?


Модульность означает построение магазина таким образом, чтобы новые функции можно было устанавливать в виде отдельных «блоков» (модулей), не затрагивая «сердце» системы. Это позволяет вам:

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


Вот как популярные платформы справляются с этой задачей:


Magento

Magento похож на LEGO для электронной коммерции, и с точки зрения модульности он является образцом для подражания. Каждое расширение имеет свою собственную папку, например, app/code/MyStore/ModuleName, что позволяет поддерживать порядок.


Код имеет слоистую структуру — бизнес-логика отделена от представлений и базы данных. Это похоже на разделение кухни, столовой и посудомоечной машины — каждая выполняет свою функцию.


Плюсы:

  • Очень хорошее разделение задач,
  • Организованная структура,
  • Более простая изоляция ошибок.


Минусы:

  • Система сложна — не каждый разработчик может понять ее без опыта.


Оценка: 5/5. Отличная модульность, но требует опытных разработчиков.


Prestashop

PrestaShop также основан на модулях — каждый модуль имеет свою структуру и является отдельным. Начиная с версии 1.7, платформа использует Symfony и Twig. Это означает более профессиональную архитектуру, более четкое разделение и большие возможности.


Плюсы:

  • Модули не затрагивают ядро,
  • Более простые обновления,
  • Современная архитектура (Symfony, Twig).


Минусы:

  • Старые версии были значительно слабее в этом плане.


Оценка: 4/5. Новые версии намного лучше, но наследие старых решений все еще может быть проблемой.


OpenCart 4

OpenCart 4 сделал большой качественный скачок в архитектуре и организации кода. Он по-прежнему следует MVCL (Model–View–Controller–Language), но теперь четко разделяет системные и внешние файлы.


Что это означает?

Расширения, темы, модули и интеграции больше не смешиваются с системными файлами — все находится в каталоге extension/.


Преимущества:

  • Обновления ядра не перезаписывают расширения,
  • Четкое разделение системных и пользовательских файлов,
  • Более упорядоченный и легкий в отладке код.


Дополнительные возможности:

  • Шаблонный движок Twig повышает безопасность (например, автоматический экранирование),
  • Система событий позволяет изменять поведение без изменения кода ядра,
  • Классическое разделение admin/ и catalog/ сохраняется для каждого плагина.


Оценка: 5/5. Самая организованная версия OpenCart на сегодняшний день.


Woocommerce

WooCommerce — это плагин WordPress, а расширения — это дополнительные плагины. Каждый из них имеет свою папку, код и стиль. WordPress рекомендует использовать определенную структуру (includes/, assets/, templates/), но ничто не мешает разработчику создать беспорядок.


Плюсы:

  • Очень гибкий,
  • Доступно много дополнений.


Минусы:

  • Качество плагинов сильно варьируется,
  • Ограниченный контроль над системой — если плагин плохо написан, качество будет низким.


Оценка: 4/5. Гибкость — это плюс, но качество плагинов и ограниченный контроль создают риски.


Таблица безопасности для интернет-магазинов — время для обзора!


1. Mageto – 27 из 30 баллов

Magento набирает наибольшее количество баллов. Он создан для крупных магазинов, больших нагрузок и высоких рисков. В нем есть все: защита от XSS, CSRF, SQLi, защита от брутфорса, reCAPTCHA, 2FA, многоуровневая архитектура и даже официальная программа поощрения за обнаружение уязвимостей. Но для его использования требуются знания, люди и ресурсы.


Идеально подходит для: крупных игроков с IT-командой и большим бюджетом.


2. OpenCart 4 – 25 баллов

Сюрприз? Только для тех, кто не знает об этом. OpenCart 4 претерпел огромные изменения в области безопасности: автоматический экранирование Twig, перемещение каталога хранения, ограничение скорости входа, разделение каталогов расширений — и все это в системе, которая остается простой, быстрой и с открытым исходным кодом (поэтому мы любим эту платформу и специализируемся на ней).


Идеально подходит для: малых и средних предприятий, которые хотят получить безопасное решение без 10 плагинов для каждой функции.


3. Prestashop — 20 баллов

Presta — это открытый исходный код, но ему немного не хватает дисциплины в вопросах безопасности. Модули могут быть тикающими бомбами замедленного действия. Множество возможностей — и множество уязвимостей и исторических инцидентов. Бонусные баллы за переход на Symfony и Twig, но это не уровень Magento или OpenCart.


Идеально подходит для: тех, кто уже использует Presta и может хорошо им управлять.


4. Woocommerce – 17 баллов

WordPress + WooCommerce – это как отношения с человеком, у которого есть прошлое: все кажется в порядке, но… плагины, плагины и еще раз плагины. 96% уязвимостей исходят от плагинов. Теоретически вы можете достичь уровня безопасности корпоративного класса, но один плохой плагин может все разрушить.


Идеально подходит для: блогеров, инфлюенсеров или людей, которые очень хорошо знают WordPress и знают, что не следует устанавливать.


Выводы

Лучший баланс безопасности, простоты и расширяемости? OpenCart 4.

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


OpenCart также лидирует среди платформ электронной коммерции.


Наибольшее количество баллов? Magento. Это как большой поезд — он может отвезти вас очень далеко, но вам нужны правильные рельсы и станция.


В конце концов, самое важное — не то, что вы выбираете, а то, как вы этим управляете. Даже лучшая система не будет работать, если вы ее не обновляете.


Если у вас есть устаревший магазин OpenCart и вы хотите его обновить и улучшить безопасность, свяжитесь с нами, и мы вам поможем.


Ссылки и ресурсы, использованные в статье

[1] MGT-COMMERCE – “Magento XSS Protection Techniques to Prevent Data Breaches”

[2] Cybersecurity - “Severe remote code execution vulnerability in PrestaShop: Update immediately”

[3] Security Week - “8,000 New WordPress Vulnerabilities Reported in 2024”

[4] Adobe Developer - “Cross-site request forgery (CSRF)”

[5] CloudDefense.AI - “CVE-2023-25170 : What You Need to Know” 

[6] Cloudfy - “Magento Supply Chain Attack: What It Means for B2B Ecommerce and Why SaaS Security Matters”

[7] Bleeping Computer - “Facebook PrestaShop module exploited to steal credit cards” 


При подготовке статьи использовалась информация, представленная в публикации Design Cart «Безопасность интернет-магазинов – рейтинг интернет-магазинов по уровню безопасности», а также несколько статей из Википедии.