Rozwikłanie CORS: Dogłębne spojrzenie na obsługę żądań Preflight w JavaScript

W ciągle rozwijającym się świecie tworzenia stron internetowych bezpieczeństwo jest najważniejsze. Cross-Origin Resource Sharing (CORS) to kluczowy mechanizm bezpieczeństwa zaimplementowany przez przeglądarki internetowe, aby ograniczyć stronom internetowym możliwość wysyłania żądań do domeny innej niż ta, która obsługiwała daną stronę. Jest to podstawowa funkcja bezpieczeństwa zaprojektowana w celu zapobiegania dostępowi złośliwych witryn do poufnych danych. Ten obszerny przewodnik zagłębi się w zawiłości CORS, koncentrując się w szczególności na obsłudze żądań preflight. Zbadamy "dlaczego", "co" i "jak" CORS, dostarczając praktyczne przykłady i rozwiązania typowych problemów napotykanych przez programistów na całym świecie.

Zrozumienie polityki tego samego pochodzenia

U podstaw CORS leży Polityka Tego Samego Pochodzenia (SOP). Polityka ta to mechanizm bezpieczeństwa na poziomie przeglądarki, który ogranicza skryptom działającym w jednym pochodzeniu dostęp do zasobów z innego pochodzenia. Pochodzenie jest definiowane przez protokół (np. HTTP lub HTTPS), domenę (np. example.com) i port (np. 80 lub 443). Dwa adresy URL mają to samo pochodzenie, jeśli te trzy komponenty dokładnie się zgadzają.

Na przykład:

• https://www.example.com/app1/index.html i https://www.example.com/app2/index.html mają to samo pochodzenie (ten sam protokół, domena i port).
• https://www.example.com/index.html i http://www.example.com/index.html mają różne pochodzenia (różne protokoły).
• https://www.example.com/index.html i https://api.example.com/index.html mają różne pochodzenia (różne subdomeny są traktowane jako różne domeny).
• https://www.example.com:8080/index.html i https://www.example.com/index.html mają różne pochodzenia (różne porty).

SOP ma na celu zapobieganie dostępowi złośliwych skryptów na jednej stronie internetowej do poufnych danych, takich jak pliki cookie lub informacje uwierzytelniające użytkownika, na innej stronie. Choć jest to kluczowe dla bezpieczeństwa, SOP może być również restrykcyjne, zwłaszcza gdy potrzebne są legalne żądania między źródłami.

Czym jest Cross-Origin Resource Sharing (CORS)?

CORS to mechanizm, który umożliwia serwerom określanie, które pochodzenia (domeny, schematy lub porty) mają dostęp do ich zasobów. Zasadniczo rozluźnia on SOP, umożliwiając kontrolowany dostęp między źródłami. CORS jest zaimplementowany za pomocą nagłówków HTTP, które są wymieniane między klientem (zazwyczaj przeglądarką internetową) a serwerem.

Gdy przeglądarka wysyła żądanie między źródłami (tj. żądanie do innego pochodzenia niż bieżąca strona), najpierw sprawdza, czy serwer zezwala na to żądanie. Odbywa się to poprzez analizę nagłówka Access-Control-Allow-Origin w odpowiedzi serwera. Jeśli pochodzenie żądania jest wymienione w tym nagłówku (lub jeśli nagłówek jest ustawiony na *, zezwalając na wszystkie pochodzenia), przeglądarka pozwala na kontynuowanie żądania. W przeciwnym razie przeglądarka blokuje żądanie, uniemożliwiając kodowi JavaScript dostęp do danych odpowiedzi.

Rola żądań Preflight

Dla niektórych typów żądań między źródłami przeglądarka inicjuje żądanie preflight. Jest to żądanie OPTIONS wysyłane do serwera przed właściwym żądaniem. Celem żądania preflight jest ustalenie, czy serwer jest gotów zaakceptować właściwe żądanie. Serwer odpowiada na żądanie preflight informacjami o dozwolonych metodach, nagłówkach i innych ograniczeniach.

Żądania preflight są wyzwalane, gdy żądanie między źródłami spełnia którykolwiek z następujących warunków:

• Metoda żądania nie jest GET, HEAD ani POST.
• Żądanie zawiera niestandardowe nagłówki (tj. nagłówki inne niż te automatycznie dodawane przez przeglądarkę).
• Nagłówek Content-Type jest ustawiony na cokolwiek innego niż application/x-www-form-urlencoded, multipart/form-data lub text/plain.
• Żądanie używa obiektów ReadableStream w treści.

Na przykład, żądanie PUT z nagłówkiem Content-Type ustawionym na application/json wywoła żądanie preflight, ponieważ używa innej metody niż dozwolone i potencjalnie niedozwolonego typu zawartości.

Dlaczego żądania Preflight?

Żądania preflight są niezbędne dla bezpieczeństwa, ponieważ dają serwerowi możliwość odrzucenia potencjalnie szkodliwych żądań między źródłami, zanim zostaną one wykonane. Bez żądań preflight, złośliwa strona internetowa mogłaby potencjalnie wysyłać dowolne żądania do serwera bez jego wyraźnej zgody. Żądanie preflight pozwala serwerowi zweryfikować, czy żądanie jest akceptowalne i zapobiega potencjalnie szkodliwym operacjom.

Obsługa żądań Preflight po stronie serwera

Prawidłowa obsługa żądań preflight jest kluczowa dla zapewnienia, że aplikacja internetowa działa poprawnie i bezpiecznie. Serwer musi odpowiedzieć na żądanie OPTIONS z odpowiednimi nagłówkami CORS, aby wskazać, czy właściwe żądanie jest dozwolone.

Oto zestawienie kluczowych nagłówków CORS używanych w odpowiedziach preflight:

• Access-Control-Allow-Origin: Ten nagłówek określa pochodzenia, które mają dostęp do zasobu. Może być ustawiony na konkretne pochodzenie (np. https://www.example.com) lub na *, aby zezwolić na wszystkie pochodzenia. Jednak używanie * jest generalnie odradzane ze względów bezpieczeństwa, zwłaszcza jeśli serwer obsługuje poufne dane.
• Access-Control-Allow-Methods: Ten nagłówek określa metody HTTP dozwolone dla żądania między źródłami (np. GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Ten nagłówek określa listę niestandardowych nagłówków HTTP dozwolonych w właściwym żądaniu. Jest to konieczne, jeśli klient wysyła niestandardowe nagłówki, takie jak X-Custom-Header lub Authorization.
• Access-Control-Allow-Credentials: Ten nagłówek wskazuje, czy właściwe żądanie może zawierać poświadczenia, takie jak pliki cookie lub nagłówki autoryzacyjne. Musi być ustawiony na true, jeśli kod po stronie klienta wysyła poświadczenia, a serwer powinien je zaakceptować. Uwaga: gdy ten nagłówek jest ustawiony na `true`, `Access-Control-Allow-Origin` *nie może* być ustawiony na `*`. Musisz określić pochodzenie.
• Access-Control-Max-Age: Ten nagłówek określa maksymalny czas (w sekundach), przez jaki przeglądarka może buforować odpowiedź preflight. Może to pomóc w poprawie wydajności poprzez zmniejszenie liczby wysyłanych żądań preflight.

Przykład: Obsługa żądań Preflight w Node.js z Express

Oto przykład, jak obsługiwać żądania preflight w aplikacji Node.js za pomocą frameworka Express:

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

// Enable CORS for all origins (for development purposes only!)
// In production, specify allowed origins for better security.
app.use(cors()); //or app.use(cors({origin: 'https://www.example.com'}));

// Route for handling OPTIONS requests (preflight)
app.options('/data', cors()); // Enable CORS for a single route. Or specify origin: cors({origin: 'https://www.example.com'})

// Route for handling GET requests
app.get('/data', (req, res) => {
  res.json({ message: 'This is cross-origin data!' });
});


// Route to handle a preflight and a post request
app.options('/resource', cors()); // enable pre-flight request for DELETE request
app.delete('/resource', cors(), (req, res, next) => {
  res.send('delete resource')
})


const port = 3000;
app.listen(port, () => {
  console.log(`Server listening on port ${port}`);
});

W tym przykładzie używamy oprogramowania pośredniczącego cors do obsługi żądań CORS. Aby uzyskać bardziej szczegółową kontrolę, CORS można włączyć dla poszczególnych tras. Uwaga: w środowisku produkcyjnym zdecydowanie zaleca się określenie dozwolonych pochodzeń za pomocą opcji origin zamiast zezwalania na wszystkie pochodzenia. Zezwalanie na wszystkie pochodzenia za pomocą * może narazić aplikację na luki w zabezpieczeniach.

Przykład: Obsługa żądań Preflight w Pythonie z Flask

Oto przykład, jak obsługiwać żądania preflight w aplikacji Python za pomocą frameworka Flask i rozszerzenia flask_cors:

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

app = Flask(__name__)
CORS(app)  # Enable CORS for all routes

@app.route('/data')
@cross_origin()
def get_data():
    data = {"message": "This is cross-origin data!"}
    return jsonify(data)

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

Jest to najprostsze użycie. Podobnie jak poprzednio, pochodzenia mogą być ograniczone. Szczegóły można znaleźć w dokumentacji flask-cors.

Przykład: Obsługa żądań Preflight w Javie z Spring Boot

Oto przykład, jak obsługiwać żądania preflight w aplikacji Java za pomocą 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");
            }
        };
    }
}

I odpowiadający mu kontroler:

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

@RestController
public class DataController {

    @GetMapping("/data")
    public String getData() {
        return "This is cross-origin data!";
    }
}

Typowe problemy i rozwiązania CORS

Pomimo swojego znaczenia, CORS często może być źródłem frustracji dla programistów. Oto kilka typowych problemów z CORS i ich rozwiązania:

1. Błąd: "No 'Access-Control-Allow-Origin' header is present on the requested resource."

   Ten błąd wskazuje, że serwer nie zwraca nagłówka Access-Control-Allow-Origin w swojej odpowiedzi. Aby to naprawić, upewnij się, że serwer jest skonfigurowany tak, aby zawierał ten nagłówek i że jest on ustawiony na poprawne pochodzenie lub na * (jeśli to właściwe).

   Rozwiązanie: Skonfiguruj serwer tak, aby zawierał nagłówek `Access-Control-Allow-Origin` w swojej odpowiedzi, ustawiając go na pochodzenie żądającej witryny lub na `*`, aby zezwolić na wszystkie pochodzenia (używaj ostrożnie).

2. Błąd: "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."

   Ten błąd wskazuje, że serwer nie zezwala na niestandardowy nagłówek (X-Custom-Header w tym przykładzie) w żądaniu między źródłami. Aby to naprawić, upewnij się, że serwer zawiera ten nagłówek w nagłówku Access-Control-Allow-Headers w odpowiedzi preflight.

   Rozwiązanie: Dodaj niestandardowy nagłówek (np. `X-Custom-Header`) do nagłówka `Access-Control-Allow-Headers` w odpowiedzi preflight serwera.

3. Błąd: "Credentials flag is 'true', but the 'Access-Control-Allow-Origin' header is '*'."

   Gdy nagłówek Access-Control-Allow-Credentials jest ustawiony na true, nagłówek Access-Control-Allow-Origin musi być ustawiony na konkretne pochodzenie, a nie na *. Wynika to z faktu, że zezwolenie na poświadczenia ze wszystkich pochodzeń stanowiłoby ryzyko bezpieczeństwa.

   Rozwiązanie: Przy użyciu poświadczeń, ustaw `Access-Control-Allow-Origin` na konkretne pochodzenie zamiast `*`.

4. Żądanie preflight nie jest wysyłane.

   Dokładnie sprawdź, czy Twój kod Javascript zawiera właściwość `credentials: 'include'`. Sprawdź również, czy Twój serwer zezwala na `Access-Control-Allow-Credentials: true`.

5. Sprzeczne konfiguracje między serwerem a klientem.

   Dokładnie sprawdź konfigurację CORS po stronie serwera wraz z ustawieniami po stronie klienta. Niezgodności (np. serwer zezwala tylko na żądania GET, ale klient wysyła POST) spowodują błędy CORS.

CORS i najlepsze praktyki bezpieczeństwa

Chociaż CORS umożliwia kontrolowany dostęp między źródłami, istotne jest przestrzeganie najlepszych praktyk bezpieczeństwa w celu zapobiegania lukom:

• Unikaj używania * w nagłówku Access-Control-Allow-Origin w środowisku produkcyjnym. Umożliwia to wszystkim pochodzeniom dostęp do Twoich zasobów, co może stanowić ryzyko bezpieczeństwa. Zamiast tego określ dokładnie dozwolone pochodzenia.
• Starannie rozważ, które metody i nagłówki zezwolić. Zezwól tylko na metody i nagłówki, które są absolutnie niezbędne do prawidłowego działania aplikacji.
• Wdrażaj odpowiednie mechanizmy uwierzytelniania i autoryzacji. CORS nie zastępuje uwierzytelniania i autoryzacji. Upewnij się, że Twoje API jest chronione odpowiednimi środkami bezpieczeństwa.
• Waliduj i sanitizuj wszystkie dane wejściowe użytkownika. Pomaga to zapobiegać atakom typu cross-site scripting (XSS) i innym lukom.
• Utrzymuj aktualną konfigurację CORS po stronie serwera. Regularnie przeglądaj i aktualizuj konfigurację CORS, aby upewnić się, że jest zgodna z wymaganiami bezpieczeństwa Twojej aplikacji.

CORS w różnych środowiskach programistycznych

Problemy z CORS mogą objawiać się różnie w zależności od środowiska programistycznego i technologii. Oto jak podejść do CORS w kilku typowych scenariuszach:

Lokalne środowiska programistyczne

Podczas lokalnego rozwoju problemy z CORS mogą być szczególnie uciążliwe. Przeglądarki często blokują żądania z lokalnego serwera deweloperskiego (np. localhost:3000) do zdalnego API. Kilka technik może złagodzić ten problem:

• Rozszerzenia przeglądarki: Rozszerzenia takie jak "Allow CORS: Access-Control-Allow-Origin" mogą tymczasowo wyłączyć ograniczenia CORS do celów testowych. Jednak *nigdy* nie używaj ich w środowisku produkcyjnym.
• Serwery proxy: Skonfiguruj serwer proxy, który przekierowuje żądania z Twojego lokalnego serwera deweloperskiego do zdalnego API. To skutecznie sprawia, że żądania są "tego samego pochodzenia" z perspektywy przeglądarki. Narzędzia takie jak http-proxy-middleware (dla Node.js) są pomocne w tym zakresie.
• Konfiguracja CORS serwera: Nawet podczas rozwoju najlepiej jest skonfigurować serwer API tak, aby jawnie zezwalał na żądania z lokalnego pochodzenia deweloperskiego (np. http://localhost:3000). To symuluje rzeczywistą konfigurację CORS i pomaga wcześnie wychwycić problemy.

Środowiska bezserwerowe (np. AWS Lambda, Google Cloud Functions)

Funkcje bezserwerowe często wymagają starannej konfiguracji CORS. Wiele platform bezserwerowych oferuje wbudowaną obsługę CORS, ale kluczowe jest jej prawidłowe skonfigurowanie:

• Ustawienia specyficzne dla platformy: Użyj wbudowanych opcji konfiguracji CORS danej platformy. AWS Lambda, na przykład, pozwala określić dozwolone pochodzenia, metody i nagłówki bezpośrednio w ustawieniach API Gateway.
• Middleware/Biblioteki: Dla większej elastyczności możesz używać middleware lub bibliotek do obsługi CORS w kodzie funkcji bezserwerowej. Jest to podobne do podejść stosowanych w tradycyjnych środowiskach serwerowych (np. użycie pakietu `cors` w funkcjach Node.js Lambda).
• Rozważ metodę `OPTIONS`: Upewnij się, że Twoja funkcja bezserwerowa prawidłowo obsługuje żądania OPTIONS. Często wiąże się to z utworzeniem oddzielnej trasy, która zwraca odpowiednie nagłówki CORS.

Tworzenie aplikacji mobilnych (np. React Native, Flutter)

CORS jest mniej bezpośrednim problemem dla natywnych aplikacji mobilnych (Android, iOS), ponieważ zazwyczaj nie wymuszają one polityki tego samego pochodzenia w taki sam sposób jak przeglądarki internetowe. Jednak CORS może być nadal istotny, jeśli Twoja aplikacja mobilna używa widoku internetowego do wyświetlania treści internetowych lub jeśli używasz frameworków takich jak React Native lub Flutter, które wykorzystują JavaScript:

• Widoki internetowe: Jeśli Twoja aplikacja mobilna używa widoku internetowego do wyświetlania treści internetowych, obowiązują te same zasady CORS co w przeglądarce internetowej. Skonfiguruj serwer tak, aby zezwalał na żądania z pochodzenia treści internetowych.
• React Native/Flutter: Te frameworki używają JavaScript do wykonywania żądań API. Chociaż środowisko natywne może nie wymuszać CORS bezpośrednio, bazowe klienty HTTP (np. fetch) mogą nadal wykazywać zachowania podobne do CORS w pewnych sytuacjach.
• Natywne klienty HTTP: Podczas wykonywania żądań API bezpośrednio z kodu natywnego (np. za pomocą OkHttp na Androidzie lub URLSession na iOS), CORS zazwyczaj nie jest czynnikiem. Nadal jednak musisz wziąć pod uwagę najlepsze praktyki bezpieczeństwa, takie jak właściwe uwierzytelnianie i autoryzacja.

Globalne aspekty konfiguracji CORS

Podczas konfigurowania CORS dla globalnie dostępnej aplikacji, kluczowe jest uwzględnienie czynników takich jak:

• Suwerenność danych: Przepisy w niektórych regionach wymagają, aby dane znajdowały się w danym regionie. CORS może być zaangażowany podczas uzyskiwania dostępu do zasobów transgranicznych, potencjalnie naruszając przepisy dotyczące rezydencji danych.
• Regionalne polityki bezpieczeństwa: Różne kraje mogą mieć odmienne przepisy i wytyczne dotyczące cyberbezpieczeństwa, które wpływają na sposób implementacji i zabezpieczania CORS.
• Sieci dostarczania treści (CDN): Upewnij się, że Twój CDN jest prawidłowo skonfigurowany, aby przekazywać niezbędne nagłówki CORS. Niewłaściwie skonfigurowane CDN-y mogą usuwać nagłówki CORS, prowadząc do nieoczekiwanych błędów.
• Load Balancers i Proxy: Sprawdź, czy wszelkie load balancery lub reverse proxy w Twojej infrastrukturze prawidłowo obsługują żądania preflight i przekazują nagłówki CORS.
• Obsługa wielu języków: Rozważ, jak CORS współdziała ze strategiami internacjonalizacji (i18n) i lokalizacji (l10n) Twojej aplikacji. Upewnij się, że polityki CORS są spójne we wszystkich wersjach językowych Twojej aplikacji.

Testowanie i debugowanie CORS

Skuteczne testowanie i debugowanie CORS jest kluczowe. Oto kilka technik:

• Narzędzia deweloperskie przeglądarki: Konsola deweloperska przeglądarki to Twój pierwszy przystanek. Zakładka "Sieć" pokaże żądania preflight i odpowiedzi, ujawniając, czy nagłówki CORS są obecne i poprawnie skonfigurowane.
• `curl` Narzędzie wiersza poleceń: Użyj `curl -v -X OPTIONS `, aby ręcznie wysłać żądania preflight i sprawdzić nagłówki odpowiedzi serwera.
• Internetowe narzędzia do sprawdzania CORS: Liczne narzędzia online mogą pomóc zweryfikować konfigurację CORS. Wystarczy wyszukać "CORS checker".
• Testy jednostkowe i integracyjne: Napisz zautomatyzowane testy, aby sprawdzić, czy konfiguracja CORS działa zgodnie z oczekiwaniami. Testy te powinny obejmować zarówno udane żądania między źródłami, jak i scenariusze, w których CORS powinien blokować dostęp.
• Logowanie i monitorowanie: Wdrażaj logowanie w celu śledzenia zdarzeń związanych z CORS, takich jak żądania preflight i zablokowane żądania. Monitoruj dzienniki pod kątem podejrzanej aktywności lub błędów konfiguracji.

Podsumowanie

Cross-Origin Resource Sharing (CORS) to kluczowy mechanizm bezpieczeństwa, który umożliwia kontrolowany dostęp między źródłami do zasobów internetowych. Zrozumienie, jak działa CORS, zwłaszcza żądania preflight, jest kluczowe dla budowania bezpiecznych i niezawodnych aplikacji internetowych. Stosując najlepsze praktyki przedstawione w tym przewodniku, możesz skutecznie radzić sobie z problemami CORS i chronić swoją aplikację przed potencjalnymi lukami. Pamiętaj, aby zawsze priorytetyzować bezpieczeństwo i dokładnie rozważyć implikacje konfiguracji CORS.

W miarę ewolucji rozwoju stron internetowych, CORS będzie nadal kluczowym aspektem bezpieczeństwa w sieci. Pozostawanie na bieżąco z najnowszymi najlepszymi praktykami i technikami CORS jest niezbędne do budowania bezpiecznych i globalnie dostępnych aplikacji internetowych.