Rsa97

no-cors это вообще из другой оперы. Эта опция позволяет выполнить только простой запрос (HEAD, GET, POST) с ограниченным набором заголовков (Accept, Accept-Language, Content-Language, Content-Type и Range), но не даёт JS доступа к свойствам Response, то есть телу и заголовкам ответа.

Сама политика CORS контролируется браузером и не даёт делать cross-origin запросы, если сервер, к которому сделан запрос, не возвращает явного разрешения на это в заголовках ответа. Для обхода надо делать запрос через свой бэкенд, который выполняет в этом случае роль прокси для внешнего ресурса.

Всё очень просто. Если страница в браузере загрузилась с одного источника (пусть это будет основное приложение), а обращается к другому (пусть это будет API), то включается защита CORS, встроенная в браузер. Разными считаются источники у которых что-то отличается: протокол (http / https), доменное имя и/или порт.
Для обхода защиты API должен возвращать ответ с набором CORS-заголовков, разрешающих, как минимум, конкретный тип запроса (GET, POST, OPTIONS и т.п.) и источник основного приложения.
Если API принадлежит не вам и вы не в состоянии установить нужные заголовки ответа прямо на нём, то единственный вариант - проксировать запрос через свой бэкенд с добавлением заголовков. То есть, ваша страница делает запрос к вашему бэкенду, ваш бэкенд запрашивает стороннее API, получает от него ответ и возвращает его вашей странице.

У вас в политике не хватает разрешения на OPTIONS, который используется в префлайт-запросах.
https://developer.mozilla.org/en-US/docs/Glossary/...

Добавить в заголовок Access-Control-Allow-Headers ответа разрешение на заголовок x-csrf-token

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

В ответ на preflight-запрос OPTIONS с сервера возвращается ответ с кодом, отличным от 2xx.
Postman игнорирует политику CORS, поэтому им проверять надо по отдельности запрос OPTIONS и запрос POST.

https://developer.mozilla.org/en/docs/Web/HTTP/CORS
Если вкратце, то доступ со страницы, открытой в браузере с одного домена (foo.com) к другому домену (buz.com) требует, чтобы сервер buz.com возвращал заголовки явно разрешающие доступ для foo.com.
Это ограничение вшито в браузеры и обходится проксированием запроса через свой бэкенд.
Скрипт в браузере со страницы foo.com обращается к бэкенду foo.com, тот делает запрос к buz.com и возвращает ответ браузеру.

В ответ на запрос OPTIONS должны вернуться CORS-заголовки. У вас в ответе их нет.
И ставить Access-Control-Allow-Origin в заголовки запроса бессмысленно, это заголовок только для ответа.

localhost и localhost:19006 - это разные сайты с точки зрения браузера.
Необходимо возвращать CORS-заголовки, в том числе и на запросы OPTIONS.

header('Access-Control-Allow-Origin: ' . $_SERVER['HTTP_ORIGIN']);
header('Access-Control-Allow-Credentials: true');
header('Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept');
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
header('Vary: Origin');

А если используете куки, то надо ещё и устанавливать withCredentials=true для AJAX-запросов.

В определённых случаях браузер делает preflight request. Сначала ресурс запрашивается методом OPTIONS, на который браузер рассчитывает получить ответ 200 с установленными CORS-заголовками. И только если этот запрос прошёл, то делается основной запрос.
Проверьте, что ваш сервер нормально отвечает на OPTIONS.

Вопрос всплывает здесь по несколько раз за день.
Эти заголовки должен отдавать сервер. Гуглите CORS.

Потому что в ответах нет CORS-заголовков.
lazuren.ru и api.lazuren.ru - это два разных домена и, когда страница, открытая с одного домена, обращается к другому домену, браузер требует CORS-заголовков либо в ответе на сам запрос, либо в ответе на предварительный запрос OPTIONS.
https://developer.mozilla.org/ru/docs/Web/HTTP/CORS

Делайте запрос к скрипту на своём сайте, чтобы уже он делал запрос к стороннему ресурсу. CORS-защита сейчас есть у всех браузеров.