Чем опасно указывать Access-Control-Allow-Origin: * (разрешить доступ к ресурсу из любого источник) на сервере?

Question

[gera7]

Есть платежная система, запросы на создание платежей осуществляются по API.
Её документация написана под .php, но я знаю JavaScript и пробую отправлять XMLHttpRequest/Fetch запросы, при этом ловлю ошибку:
"No 'Access-Control-Allow-Origin'

На сейчас я вижу 2 варианта:
1. Поднять свой прокси сервер для обхода CORS. Запросы уходя на прокси, прокси отправляет запрос на сервер и получает ответ к которому добавляет Access-Control-Allow-Origin и присылает браузеру. (этот вариант рабочий, тестил на общедоступном прокси серваке).
2. Написать в поддержку платежной системы и попросить добавить Access-Control-Allow-Origin: *

Вопрос:
1. Какие минусы у первого варианта?
2. Чем опасно для платежной системы разрешить доступ к ресурсу из любого источника согласно 2 варианта?
3. Возможно ли внесение правок с их стороны или меня проигнорируют?

Если Access-Control-Allow-Origin: * небезопасный метод, почему в таком случае его так легко обойти через прокси?

Comments

[Алексей Ярков]

С второго варианта прям взоржал аки конь ))
Никто этого делать не будет, не фантазируйте.
Поднимайте бэкенд и через него делайте запрос.

[gera7]

Алексей Ярков, вы бы могли взоржать с 3 вопроса, а по существу ответить на 2.

[Алексей Ярков]

gera7, мог бы, если бы был третий ВАРИАНТ



По существу я ответил. Только свой бэкенд, без вариантов. Никто ради вас не будет ничего менять.

[gera7]

Алексей Ярков, варианты не требуют вашего ржача и домыслов на тему кто и что может ради меня сделать.
Интересно получить ответы на вопросы, которые указаны ниже. Ваше мнение по 3 ВОПРОСу я уже понял, спасибо.

[profesor08]

Алексей Ярков, глупости, вполне себе дорабатывают функционал по запросам клиентов, если они адекватные. Этот вопрос вполне себе адекватен.

[Денис Юрьев]

profesor08, с фронта стучаться в апи платежки это вполне себе неадекватно.

[Денис Юрьев]

Aleksandr-JS-Developer, мне кажется автор мануалы банка не дочитал просто

[gera7]

Aleksandr-JS-Developer, уточните, пожалуйста, какие именно "две кнопки", по вашему, я не могу нажать? И что я пропустил в мануале по основам http?

Answer 1

[Анатолий Медведев]

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

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

3. Возможно ли внесение правок с их стороны или меня проигнорируют?

Над вами посмеются, попадёте в юмористическую подборку "клиент хочет странного" во внутренней рассылке.

1. Какие минусы у первого варианта?

Ну это уже ваш ресурс и его уязвимости.

Comments

[profesor08]

глупости

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

запрос в любом случае улетает на сервер, и в зависимости от origin, браузер решает, отбросить ответ или нет.

Answer 2

[profesor08]

2. Написать в поддержку платежной системы и попросить добавить Access-Control-Allow-Origin: *

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

Поднять свой прокси сервер для обхода CORS

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

Либо заморочиться с отдельным прокси.

Comments

[gera7]

Спасибо, поинтересуюсь возможность.

Да, со своей стороны возможно 2 реализации:
1. Отправлять запросы на .php скрипт.
2. Поднимать прокси.

Answer 3

[SagePtr]

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

Comments

[gera7]

Да, я это понимаю, но у платежной системы есть клиент-серверное взаимодействие через отправку формы запроса платежа (HTML-форма), после отправки которой идет редирект на их веб-шлюз.
И также, есть более продвинутый вариант взаимодействия, реализация которого уже описана под .php скрипт, суть её заключается в том, что после отправки запроса на проведение платежа, в ответ приходит ссылка на которую в дальнейшем необходимо выполнить редирект клиента.
Да, я понимаю что более правильно организовать взаимодействие сервер-сервер, но взаимодействие с серверной частью (в условиях поставленной задачи) недоступно и есть лишь фронт.

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

Вопрос стоит именно в обходе защиты браузеров.

[SagePtr]

gera7, если на бэке ничего ловить не собираетесь, то зачем вообще использовать в таком случае API? Укажите реквизиты, по которым принимаете платежи, и этого будет достаточно.