Каков ожидаемый ответ на недопустимый запрос CORS?

В спецификации CORS не говорится о том, как серверы должны реагировать на недопустимые запросы CORS. Например, если запрос Origin недействителен, CORS spec утверждает: "завершите этот набор шагов. Запрос выходит за рамки этой спецификации" . Аналогичный язык существует для других случаев ошибок, таких как запрос недопустимых методов или заголовков.

Каким должен быть ожидаемый ответ в случае ошибок CORS? Я понимаю, что для разных серверов может потребоваться другое поведение. Но я ищу стандартный ответ или ответы, которые могут быть приемлемыми, если владельцу сервера все равно.

Ответ 1

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

1) Верните ошибку, если запрос CORS недействителен. Это маршрут, принятый фильтр Java CORS проект. Эта библиотека возвращает

400 Плохой запрос для запросов, которые не соответствуют спецификации
403 Запрещено для недопустимых истоков или заголовков.
405 Метод Не разрешать недопустимые методы

2) Верните заголовки CORS в ответ и позвольте браузеру разобраться в деталях доступа. Это, по-видимому, гораздо более общий подход и используется API для Amazon S3, SoundCloud, FourSquare и Spotify (последние два API полезны только для поддержки простых запросов CORS). В этом случае сервер не выполняет проверку ошибок и просто возвращает заголовки CORS для поддерживаемого источника, метода и заголовков. Браузер все еще выполняет запрос, но если заголовки ответа CORS не соответствуют запросу пользователя, браузер не отвечает на него от пользователя.

Каждый из этих методов имеет свои плюсы и минусы. Метод № 1 более тесно связан с спецификацией CORS, но не предоставляет пользователю полезной информации отладки.

Метод № 2 дает более полное представление о поддерживаемых методах и заголовках. Это также проще реализовать, поскольку сервер возвращает одни и те же заголовки ответов, независимо от заголовков запросов. Однако это происходит за счет фактического выполнения запроса на стороне сервера, хотя браузер блокирует ответ от пользователя. Это может быть нежелательно для метода с побочными эффектами, таких как POST, PUT или DELETE, и подчеркивает тот факт, что CORS не следует использовать в качестве механизма аутентификации.

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

Ответ 2

Я бы ожидал, что это будет зависеть от характера ошибки, но я бы ожидал некоторую ошибку 4xx, такую как 403 (если запрос не прошел некоторые требуемые критерии) или 404 (если этот метод недоступен).

Ответ 3

Я просто хочу добавить к ответу Monsur. Есть еще одно поведение (то, которое в настоящее время используется S3):

Чтобы отправлять заголовки ответа CORS, только если они соответствуют источнику запроса. В противном случае, вообще не отправляйте заголовки CORS, и пусть ваш браузер или любой другой клиент сам решит.

По крайней мере, так у меня работает.

Кроме того, когда дело доходит до Java, обычно отправляют 403. Эта ссылка на Java довольно старая, но фактический стандарт в Java, Spring, такой же. Смотрите мою ссылку здесь.