Демістифікація CORS: Глибоке занурення в обробку попередніх запитів у JavaScript

У світі веброзробки, що постійно розширюється, безпека має першочергове значення. Cross-Origin Resource Sharing (CORS) — це ключовий механізм безпеки, реалізований веббраузерами для обмеження вебсторінок у виконанні запитів до домену, відмінного від того, що надав цю вебсторінку. Це фундаментальна функція безпеки, розроблена для запобігання доступу зловмисних вебсайтів до конфіденційних даних. Цей вичерпний посібник заглибиться в тонкощі CORS, зосереджуючись на обробці попередніх запитів. Ми розглянемо «чому», «що» і «як» стосовно CORS, надаючи практичні приклади та рішення поширених проблем, з якими стикаються розробники по всьому світу.

Розуміння політики одного джерела (Same-Origin Policy)

В основі CORS лежить політика одного джерела (Same-Origin Policy, SOP). Ця політика є механізмом безпеки на рівні браузера, який обмежує доступ скриптів, що виконуються на одному джерелі, до ресурсів з іншого джерела. Джерело (origin) визначається протоколом (наприклад, HTTP або HTTPS), доменом (наприклад, example.com) та портом (наприклад, 80 або 443). Дві URL-адреси мають однакове джерело, якщо ці три компоненти точно збігаються.

Наприклад:

• https://www.example.com/app1/index.html та https://www.example.com/app2/index.html мають однакове джерело (однаковий протокол, домен і порт).
• https://www.example.com/index.html та http://www.example.com/index.html мають різні джерела (різні протоколи).
• https://www.example.com/index.html та https://api.example.com/index.html мають різні джерела (різні субдомени вважаються різними доменами).
• https://www.example.com:8080/index.html та https://www.example.com/index.html мають різні джерела (різні порти).

SOP призначена для запобігання доступу зловмисних скриптів з одного вебсайту до конфіденційних даних, таких як файли cookie або інформація для автентифікації користувачів, на іншому вебсайті. Хоча SOP є важливою для безпеки, вона також може бути обмежувальною, особливо коли потрібні легітимні міждоменні запити.

Що таке Cross-Origin Resource Sharing (CORS)?

CORS — це механізм, який дозволяє серверам вказувати, яким джерелам (доменам, схемам або портам) дозволено отримувати доступ до їхніх ресурсів. По суті, він послаблює SOP, дозволяючи контрольований міждоменний доступ. CORS реалізується за допомогою HTTP-заголовків, якими обмінюються клієнт (зазвичай веббраузер) і сервер.

Коли браузер робить міждоменний запит (тобто запит до джерела, відмінного від поточної сторінки), він спочатку перевіряє, чи сервер дозволяє цей запит. Це робиться шляхом аналізу заголовка Access-Control-Allow-Origin у відповіді сервера. Якщо джерело запиту вказане в цьому заголовку (або якщо заголовок встановлено в *, що дозволяє всі джерела), браузер дозволяє запиту продовжитися. В іншому випадку браузер блокує запит, не дозволяючи коду JavaScript отримати доступ до даних відповіді.

Роль попередніх запитів (Preflight Requests)

Для певних типів міждоменних запитів браузер ініціює попередній запит (preflight request). Це запит з методом OPTIONS, який надсилається на сервер перед фактичним запитом. Мета попереднього запиту — визначити, чи готовий сервер прийняти фактичний запит. Сервер відповідає на попередній запит інформацією про дозволені методи, заголовки та інші обмеження.

Попередні запити спрацьовують, коли міждоменний запит відповідає будь-якій з наступних умов:

• Метод запиту не є GET, HEAD або POST.
• Запит містить користувацькі заголовки (тобто заголовки, крім тих, що автоматично додаються браузером).
• Заголовок Content-Type має значення, відмінне від application/x-www-form-urlencoded, multipart/form-data або text/plain.
• Запит використовує об'єкти ReadableStream у тілі.

Наприклад, запит PUT із Content-Type application/json викличе попередній запит, оскільки він використовує метод, відмінний від дозволених, і потенційно недозволений тип контенту.

Чому потрібні попередні запити?

Попередні запити є важливими для безпеки, оскільки вони дають серверу можливість відхилити потенційно шкідливі міждоменні запити до їх виконання. Без попередніх запитів зловмисний вебсайт міг би надсилати довільні запити на сервер без його явної згоди. Попередній запит дозволяє серверу перевірити, що запит є прийнятним, і запобігає потенційно шкідливим операціям.

Обробка попередніх запитів на стороні сервера

Правильна обробка попередніх запитів є ключовою для забезпечення коректної та безпечної роботи вашого вебзастосунку. Сервер повинен відповісти на запит OPTIONS відповідними заголовками CORS, щоб вказати, чи дозволено фактичний запит.

Ось розбір ключових заголовків CORS, які використовуються у відповідях на попередні запити:

• Access-Control-Allow-Origin: Цей заголовок вказує джерело(а), яким дозволено доступ до ресурсу. Його можна встановити на конкретне джерело (наприклад, https://www.example.com) або на *, щоб дозволити всі джерела. Однак використання * зазвичай не рекомендується з міркувань безпеки, особливо якщо сервер обробляє конфіденційні дані.
• Access-Control-Allow-Methods: Цей заголовок вказує HTTP-методи, які дозволені для міждоменного запиту (наприклад, GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Цей заголовок вказує список нестандартних HTTP-заголовків, які дозволені у фактичному запиті. Це необхідно, якщо клієнт надсилає користувацькі заголовки, такі як X-Custom-Header або Authorization.
• Access-Control-Allow-Credentials: Цей заголовок вказує, чи може фактичний запит включати облікові дані, такі як файли cookie або заголовки авторизації. Його потрібно встановити в true, якщо клієнтський код надсилає облікові дані, і сервер повинен їх приймати. Примітка: коли цей заголовок встановлено в `true`, `Access-Control-Allow-Origin` *не може* бути встановлено в `*`. Ви повинні вказати конкретне джерело.
• Access-Control-Max-Age: Цей заголовок вказує максимальний час (у секундах), протягом якого браузер може кешувати відповідь на попередній запит. Це може допомогти підвищити продуктивність, зменшивши кількість попередніх запитів, що надсилаються.

Приклад: Обробка попередніх запитів у Node.js за допомогою Express

Ось приклад того, як обробляти попередні запити в застосунку Node.js за допомогою фреймворку Express:

const express = require('express');
const cors = require('cors');
const app = express();

// Увімкнути CORS для всіх джерел (лише для розробки!)
// У продакшені вказуйте дозволені джерела для кращої безпеки.
app.use(cors()); //або app.use(cors({origin: 'https://www.example.com'}));

// Маршрут для обробки OPTIONS-запитів (попередніх)
app.options('/data', cors()); // Увімкнути CORS для одного маршруту. Або вкажіть джерело: cors({origin: 'https://www.example.com'})

// Маршрут для обробки GET-запитів
app.get('/data', (req, res) => {
  res.json({ message: 'Це міждоменні дані!' });
});


// Маршрут для обробки попереднього та post-запиту
app.options('/resource', cors()); // увімкнути попередній запит для DELETE-запиту
app.delete('/resource', cors(), (req, res, next) => {
  res.send('delete resource')
})


const port = 3000;
app.listen(port, () => {
  console.log(`Сервер слухає на порту ${port}`);
});

У цьому прикладі ми використовуємо проміжне програмне забезпечення cors для обробки запитів CORS. Для більш детального контролю CORS можна вмикати для кожного маршруту окремо. Примітка: у продакшені настійно рекомендується вказувати дозволені джерела за допомогою опції origin замість того, щоб дозволяти всі джерела. Дозвіл усіх джерел за допомогою * може наразити ваш застосунок на вразливості безпеки.

Приклад: Обробка попередніх запитів у Python за допомогою Flask

Ось приклад того, як обробляти попередні запити в застосунку Python за допомогою фреймворку Flask та розширення flask_cors:

from flask import Flask, jsonify
from flask_cors import CORS, cross_origin

app = Flask(__name__)
CORS(app)  # Увімкнути CORS для всіх маршрутів

@app.route('/data')
@cross_origin()
def get_data():
    data = {"message": "Це міждоменні дані!"}
    return jsonify(data)

if __name__ == '__main__':
    app.run(debug=True)

Це найпростіший спосіб використання. Як і раніше, джерела можна обмежувати. Детальнішу інформацію дивіться в документації flask-cors.

Приклад: Обробка попередніх запитів у Java за допомогою Spring Boot

Ось приклад того, як обробляти попередні запити в застосунку Java за допомогою Spring Boot:

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@SpringBootApplication
public class CorsApplication {

    public static void main(String[] args) {
        SpringApplication.run(CorsApplication.class, args);
    }

    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/data").allowedOrigins("http://localhost:8080");
            }
        };
    }
}

І відповідний контролер:

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class DataController {

    @GetMapping("/data")
    public String getData() {
        return "Це міждоменні дані!";
    }
}

Поширені проблеми з CORS та їх вирішення

Незважаючи на свою важливість, CORS часто може бути джерелом розчарування для розробників. Ось деякі поширені проблеми з CORS та їх вирішення:

1. Помилка: "No 'Access-Control-Allow-Origin' header is present on the requested resource."

   Ця помилка вказує на те, що сервер не повертає заголовок Access-Control-Allow-Origin у своїй відповіді. Щоб виправити це, переконайтеся, що сервер налаштований на включення цього заголовка і що він встановлений на правильне джерело або на * (якщо це доречно).

   Рішення: Налаштуйте сервер так, щоб він додавав заголовок `Access-Control-Allow-Origin` у свою відповідь, встановлюючи його на джерело вебсайту, що робить запит, або на `*` для дозволу всіх джерел (використовуйте з обережністю).

2. Помилка: "Response to preflight request doesn't pass access control check: Request header field X-Custom-Header is not allowed by Access-Control-Allow-Headers in preflight response."

   Ця помилка вказує на те, що сервер не дозволяє користувацький заголовок (X-Custom-Header у цьому прикладі) у міждоменному запиті. Щоб виправити це, переконайтеся, що сервер включає цей заголовок у заголовок Access-Control-Allow-Headers у відповіді на попередній запит.

   Рішення: Додайте користувацький заголовок (наприклад, `X-Custom-Header`) до заголовка `Access-Control-Allow-Headers` у відповіді сервера на попередній запит.

3. Помилка: "Credentials flag is 'true', but the 'Access-Control-Allow-Origin' header is '*'."

   Коли заголовок Access-Control-Allow-Credentials встановлено в true, заголовок Access-Control-Allow-Origin повинен бути встановлений на конкретне джерело, а не на *. Це пов'язано з тим, що дозвіл на передачу облікових даних з усіх джерел становив би ризик для безпеки.

   Рішення: При використанні облікових даних встановлюйте `Access-Control-Allow-Origin` на конкретне джерело замість `*`.

4. Попередній запит не надсилається.

   Двічі перевірте, що ваш код JavaScript містить властивість `credentials: 'include'`. Також перевірте, чи ваш сервер дозволяє `Access-Control-Allow-Credentials: true`.

5. Конфліктуючі конфігурації між сервером і клієнтом.

   Ретельно перевірте конфігурацію CORS на стороні сервера разом із налаштуваннями на стороні клієнта. Невідповідності (наприклад, сервер дозволяє лише GET-запити, а клієнт надсилає POST) призведуть до помилок CORS.

CORS та найкращі практики безпеки

Хоча CORS дозволяє контрольований міждоменний доступ, важливо дотримуватися найкращих практик безпеки для запобігання вразливостям:

• Уникайте використання * в заголовку Access-Control-Allow-Origin у продакшені. Це дозволяє всім джерелам отримувати доступ до ваших ресурсів, що може бути ризиком для безпеки. Замість цього вказуйте точні дозволені джерела.
• Ретельно обмірковуйте, які методи та заголовки дозволяти. Дозволяйте лише ті методи та заголовки, які є абсолютно необхідними для коректної роботи вашого застосунку.
• Впроваджуйте належні механізми автентифікації та авторизації. CORS не є заміною автентифікації та авторизації. Переконайтеся, що ваш API захищений відповідними заходами безпеки.
• Перевіряйте та санітизуйте всі вхідні дані від користувачів. Це допомагає запобігти атакам міжсайтового скриптингу (XSS) та іншим вразливостям.
• Підтримуйте конфігурацію CORS на стороні сервера в актуальному стані. Регулярно переглядайте та оновлюйте вашу конфігурацію CORS, щоб переконатися, що вона відповідає вимогам безпеки вашого застосунку.

CORS у різних середовищах розробки

Проблеми з CORS можуть проявлятися по-різному в різних середовищах розробки та технологіях. Ось як підходити до CORS у кількох поширених сценаріях:

Локальні середовища розробки

Під час локальної розробки проблеми з CORS можуть бути особливо надокучливими. Браузери часто блокують запити з вашого локального сервера розробки (наприклад, localhost:3000) до віддаленого API. Кілька технік можуть полегшити цей біль:

• Розширення для браузера: Розширення на кшталт "Allow CORS: Access-Control-Allow-Origin" можуть тимчасово вимикати обмеження CORS для тестування. Однак, *ніколи* не використовуйте їх у продакшені.
• Проксі-сервери: Налаштуйте проксі-сервер, який перенаправляє запити з вашого локального сервера розробки на віддалений API. Це фактично робить запити "однодоменними" з точки зору браузера. Інструменти, такі як http-proxy-middleware (для Node.js), є корисними для цього.
• Налаштування CORS на сервері: Навіть під час розробки найкращою практикою є налаштування вашого API-сервера так, щоб він явно дозволяв запити з вашого локального джерела розробки (наприклад, http://localhost:3000). Це імітує реальну конфігурацію CORS і допомагає виявити проблеми на ранніх етапах.

Безсерверні середовища (напр., AWS Lambda, Google Cloud Functions)

Безсерверні функції часто вимагають ретельного налаштування CORS. Багато безсерверних платформ надають вбудовану підтримку CORS, але важливо налаштувати її правильно:

• Налаштування для конкретної платформи: Використовуйте вбудовані опції конфігурації CORS платформи. AWS Lambda, наприклад, дозволяє вказувати дозволені джерела, методи та заголовки безпосередньо в налаштуваннях API Gateway.
• Проміжне ПЗ/Бібліотеки: Для більшої гнучкості ви можете використовувати проміжне ПЗ або бібліотеки для обробки CORS у коді вашої безсерверної функції. Це схоже на підходи, що використовуються в традиційних серверних середовищах (наприклад, використання пакету `cors` у функціях Node.js Lambda).
• Враховуйте метод OPTIONS: Переконайтеся, що ваша безсерверна функція правильно обробляє запити OPTIONS. Це часто включає створення окремого маршруту, який повертає відповідні заголовки CORS.

Розробка мобільних застосунків (напр., React Native, Flutter)

CORS є меншою проблемою для нативних мобільних застосунків (Android, iOS), оскільки вони зазвичай не застосовують політику одного джерела так само, як веббраузери. Однак CORS все ще може бути актуальним, якщо ваш мобільний застосунок використовує веб-перегляд для відображення вебконтенту або якщо ви використовуєте фреймворки, такі як React Native або Flutter, які використовують JavaScript:

• Веб-перегляди (Web Views): Якщо ваш мобільний застосунок використовує веб-перегляд для відображення вебконтенту, застосовуються ті ж правила CORS, що й у веббраузері. Налаштуйте ваш сервер так, щоб він дозволяв запити з джерела вебконтенту.
• React Native/Flutter: Ці фреймворки використовують JavaScript для виконання API-запитів. Хоча нативне середовище може не застосовувати CORS безпосередньо, базові HTTP-клієнти (наприклад, fetch) можуть все ще демонструвати поведінку, схожу на CORS, у певних ситуаціях.
• Нативні HTTP-клієнти: При виконанні API-запитів безпосередньо з нативного коду (наприклад, за допомогою OkHttp на Android або URLSession на iOS), CORS, як правило, не є фактором. Однак вам все одно потрібно враховувати найкращі практики безпеки, такі як належна автентифікація та авторизація.

Глобальні аспекти конфігурації CORS

При налаштуванні CORS для глобально доступного застосунку важливо враховувати такі фактори, як:

• Суверенітет даних: Нормативні акти в деяких регіонах вимагають, щоб дані зберігалися в межах регіону. CORS може бути задіяний при доступі до ресурсів через кордони, що потенційно може порушувати закони про місцезнаходження даних.
• Регіональні політики безпеки: Різні країни можуть мати різні нормативні акти та рекомендації з кібербезпеки, які впливають на те, як CORS слід впроваджувати та захищати.
• Мережі доставки контенту (CDN): Переконайтеся, що ваша CDN правильно налаштована для передачі необхідних заголовків CORS. Неправильно налаштовані CDN можуть видаляти заголовки CORS, що призводить до несподіваних помилок.
• Балансувальники навантаження та проксі: Перевірте, що будь-які балансувальники навантаження або зворотні проксі у вашій інфраструктурі правильно обробляють попередні запити та передають заголовки CORS.
• Багатомовна підтримка: Розгляньте, як CORS взаємодіє зі стратегіями інтернаціоналізації (i18n) та локалізації (l10n) вашого застосунку. Переконайтеся, що політики CORS є послідовними для різних мовних версій вашого застосунку.

Тестування та налагодження CORS

Ефективне тестування та налагодження CORS є життєво важливим. Ось деякі методи:

• Інструменти розробника в браузері: Консоль розробника у вашому браузері — це перша зупинка. Вкладка "Network" покаже попередні запити та відповіді, розкриваючи, чи присутні та правильно налаштовані заголовки CORS.
• Інструмент командного рядка `curl`: Використовуйте `curl -v -X OPTIONS `, щоб вручну надсилати попередні запити та перевіряти заголовки відповіді сервера.
• Онлайн-перевірки CORS: Численні онлайн-інструменти можуть допомогти перевірити вашу конфігурацію CORS. Просто знайдіть "CORS checker".
• Модульні та інтеграційні тести: Напишіть автоматизовані тести для перевірки того, що ваша конфігурація CORS працює, як очікувалося. Ці тести повинні охоплювати як успішні міждоменні запити, так і сценарії, де CORS повинен блокувати доступ.
• Логування та моніторинг: Впровадьте логування для відстеження подій, пов'язаних з CORS, таких як попередні запити та заблоковані запити. Відстежуйте свої логи на предмет підозрілої активності або помилок конфігурації.

Висновок

Cross-Origin Resource Sharing (CORS) є життєво важливим механізмом безпеки, який забезпечує контрольований міждоменний доступ до веб-ресурсів. Розуміння того, як працює CORS, особливо попередні запити, є вирішальним для створення безпечних і надійних вебзастосунків. Дотримуючись найкращих практик, викладених у цьому посібнику, ви можете ефективно вирішувати проблеми з CORS та захищати свій застосунок від потенційних вразливостей. Пам'ятайте, що завжди потрібно надавати пріоритет безпеці та ретельно обмірковувати наслідки вашої конфігурації CORS.

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