Implementacja zabezpieczeń Cross-Origin: Najlepsze praktyki komunikacji JavaScript

W dzisiejszym połączonym internecie aplikacje JavaScript często muszą wchodzić w interakcję z zasobami z różnych źródeł (domen, protokołów lub portów). Ta interakcja jest regulowana przez politykę tego samego pochodzenia (Same-Origin Policy) przeglądarki, kluczowy mechanizm bezpieczeństwa zaprojektowany w celu zapobiegania dostępowi złośliwych skryptów do wrażliwych danych poza granicami domeny. Jednakże, legalna komunikacja między różnymi źródłami jest często konieczna. W tym miejscu wkracza Cross-Origin Resource Sharing (CORS). Ten artykuł przedstawia kompleksowy przegląd CORS, jego implementacji oraz najlepszych praktyk bezpiecznej komunikacji między różnymi źródłami w JavaScript.

Zrozumienie polityki tego samego pochodzenia (Same-Origin Policy)

Polityka tego samego pochodzenia (Same-Origin Policy, SOP) to fundamentalna koncepcja bezpieczeństwa w przeglądarkach internetowych. Ogranicza ona skrypty działające w jednym źródle przed dostępem do zasobów z innego źródła. Źródło (origin) jest definiowane przez kombinację protokołu (np. HTTP lub HTTPS), nazwy domeny (np. example.com) i numeru portu (np. 80 lub 443). Dwa adresy URL mają to samo pochodzenie tylko wtedy, gdy wszystkie trzy komponenty są dokładnie takie same.

Na przykład:

• http://www.example.com i http://www.example.com/path: To samo pochodzenie
• http://www.example.com i https://www.example.com: Różne pochodzenie (inny protokół)
• http://www.example.com i http://subdomain.example.com: Różne pochodzenie (inna domena)
• http://www.example.com:80 i http://www.example.com:8080: Różne pochodzenie (inny port)

SOP jest kluczową obroną przed atakami Cross-Site Scripting (XSS), w których złośliwe skrypty wstrzyknięte na stronę internetową mogą kraść dane użytkownika lub wykonywać nieautoryzowane działania w jego imieniu.

Czym jest Cross-Origin Resource Sharing (CORS)?

CORS to mechanizm, który wykorzystuje nagłówki HTTP, aby umożliwić serwerom wskazanie, które źródła (domeny, schematy lub porty) mają pozwolenie na dostęp do ich zasobów. W gruncie rzeczy łagodzi on politykę tego samego pochodzenia dla określonych żądań między domenami, umożliwiając legalną komunikację, jednocześnie chroniąc przed złośliwymi atakami.

CORS działa poprzez dodanie nowych nagłówków HTTP, które określają dozwolone źródła oraz metody (np. GET, POST, PUT, DELETE) dozwolone dla żądań między domenami. Gdy przeglądarka wysyła żądanie między domenami, wysyła nagłówek Origin z żądaniem. Serwer odpowiada nagłówkiem Access-Control-Allow-Origin, który określa dozwolone źródło(a). Jeśli źródło żądania pasuje do wartości w nagłówku Access-Control-Allow-Origin (lub jeśli wartość to *), przeglądarka zezwala kodowi JavaScript na dostęp do odpowiedzi.

Jak działa CORS: Szczegółowe wyjaśnienie

Proces CORS zazwyczaj obejmuje dwa rodzaje żądań:

1. Żądania proste (Simple Requests): Są to żądania, które spełniają określone kryteria. Jeśli żądanie spełnia te warunki, przeglądarka wysyła je bezpośrednio.
2. Żądania poprzedzone zapytaniem (Preflighted Requests): Są to bardziej złożone żądania, które wymagają od przeglądarki wysłania najpierw zapytania "preflight" typu OPTIONS do serwera w celu ustalenia, czy faktyczne żądanie jest bezpieczne do wysłania.

1. Żądania proste

Żądanie jest uważane za "proste", jeśli spełnia wszystkie poniższe warunki:

• Metoda to GET, HEAD lub POST.
• Jeśli metoda to POST, nagłówek Content-Type jest jednym z następujących:
• application/x-www-form-urlencoded
• multipart/form-data
• text/plain
• Nie są ustawione żadne niestandardowe nagłówki.

Przykład prostego żądania:

GET /resource HTTP/1.1
Origin: http://www.example.com

Przykład odpowiedzi serwera zezwalającej na pochodzenie:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.example.com
Content-Type: application/json

{
  "data": "Some data"
}

Jeśli nagłówek Access-Control-Allow-Origin jest obecny, a jego wartość pasuje do pochodzenia żądania lub jest ustawiona na *, przeglądarka zezwala skryptowi na dostęp do danych odpowiedzi. W przeciwnym razie przeglądarka blokuje dostęp do odpowiedzi, a w konsoli wyświetlany jest komunikat o błędzie.

2. Żądania poprzedzone zapytaniem (Preflighted Requests)

Żądanie jest uważane za "preflighted", jeśli nie spełnia kryteriów prostego żądania. Zazwyczaj dzieje się tak, gdy żądanie używa innej metody HTTP (np. PUT, DELETE), ustawia niestandardowe nagłówki lub używa Content-Type innego niż dozwolone wartości.

Przed wysłaniem właściwego żądania, przeglądarka najpierw wysyła żądanie OPTIONS do serwera. To żądanie "preflight" zawiera następujące nagłówki:

• Origin: Pochodzenie strony wysyłającej żądanie.
• Access-Control-Request-Method: Metoda HTTP, która zostanie użyta we właściwym żądaniu (np. PUT, DELETE).
• Access-Control-Request-Headers: Lista niestandardowych nagłówków oddzielonych przecinkami, które zostaną wysłane we właściwym żądaniu.

Przykład żądania preflight:

OPTIONS /resource HTTP/1.1
Origin: http://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header, Content-Type

Serwer musi odpowiedzieć na żądanie OPTIONS następującymi nagłówkami:

• Access-Control-Allow-Origin: Pochodzenie, które może wysłać żądanie (lub *, aby zezwolić na dowolne pochodzenie).
• Access-Control-Allow-Methods: Lista metod HTTP oddzielonych przecinkami, które są dozwolone dla żądań między domenami (np. GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Lista niestandardowych nagłówków oddzielonych przecinkami, które mogą być wysyłane w żądaniu.
• Access-Control-Max-Age: Liczba sekund, przez które odpowiedź preflight może być buforowana przez przeglądarkę.

Przykład odpowiedzi serwera na żądanie preflight:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: X-Custom-Header, Content-Type
Access-Control-Max-Age: 86400

Jeśli odpowiedź serwera na żądanie preflight wskazuje, że właściwe żądanie jest dozwolone, przeglądarka wyśle właściwe żądanie. W przeciwnym razie przeglądarka zablokuje żądanie i wyświetli komunikat o błędzie.

Implementacja CORS po stronie serwera

CORS jest implementowany głównie po stronie serwera poprzez ustawienie odpowiednich nagłówków HTTP w odpowiedzi. Szczegóły implementacji będą się różnić w zależności od używanej technologii po stronie serwera.

Przykład użycia Node.js z Express:

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

// Włącz CORS dla wszystkich źródeł
app.use(cors());

// Alternatywnie, skonfiguruj CORS dla określonych źródeł
// const corsOptions = {
//   origin: 'http://www.example.com'
// };
// app.use(cors(corsOptions));

app.get('/resource', (req, res) => {
  res.json({ message: 'To jest zasób z włączonym CORS' });
});

app.listen(3000, () => {
  console.log('Serwer nasłuchuje na porcie 3000');
});

Middleware cors upraszcza proces ustawiania nagłówków CORS w Express. Możesz włączyć CORS dla wszystkich źródeł używając cors() lub skonfigurować go dla określonych źródeł używając cors(corsOptions).

Przykład użycia Python z Flask:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/resource")
def hello():
    return {"message": "To jest zasób z włączonym CORS"}

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

Rozszerzenie flask_cors zapewnia prosty sposób na włączenie CORS w aplikacjach Flask. Możesz włączyć CORS dla wszystkich źródeł, przekazując app do CORS(). Możliwa jest również konfiguracja dla określonych źródeł.

Przykład użycia Java ze Spring Boot:

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/resource")
                .allowedOrigins("http://www.example.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("Content-Type", "X-Custom-Header")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

W Spring Boot można skonfigurować CORS za pomocą WebMvcConfigurer. Pozwala to na szczegółową kontrolę nad dozwolonymi źródłami, metodami, nagłówkami i innymi ustawieniami CORS.

Bezpośrednie ustawianie nagłówków CORS (Przykład ogólny)

Jeśli nie używasz żadnego frameworka, możesz ustawić nagłówki bezpośrednio w kodzie po stronie serwera (np. PHP, Ruby on Rails, itp.):

Najlepsze praktyki CORS

Aby zapewnić bezpieczną i wydajną komunikację między różnymi źródłami, postępuj zgodnie z poniższymi najlepszymi praktykami:

1. Unikaj używania Access-Control-Allow-Origin: * w środowisku produkcyjnym: Zezwalanie wszystkim źródłom na dostęp do Twoich zasobów może stanowić ryzyko bezpieczeństwa. Zamiast tego, określ dokładnie dozwolone źródła.
2. Używaj HTTPS: Zawsze używaj HTTPS zarówno dla źródła żądającego, jak i serwującego, aby chronić dane w trakcie przesyłania.
3. Waliduj dane wejściowe: Zawsze waliduj i oczyszczaj dane otrzymane z żądań między domenami, aby zapobiec atakom typu injection.
4. Wdrażaj odpowiednie uwierzytelnianie i autoryzację: Upewnij się, że tylko autoryzowani użytkownicy mają dostęp do wrażliwych zasobów.
5. Buforuj odpowiedzi preflight: Użyj Access-Control-Max-Age do buforowania odpowiedzi preflight i zmniejszenia liczby żądań OPTIONS.
6. Rozważ użycie poświadczeń: Jeśli Twoje API wymaga uwierzytelniania za pomocą plików cookie lub uwierzytelniania HTTP, musisz ustawić nagłówek Access-Control-Allow-Credentials na true na serwerze oraz opcję credentials na 'include' w kodzie JavaScript (np. przy użyciu fetch lub XMLHttpRequest). Bądź niezwykle ostrożny przy używaniu tej opcji, ponieważ może ona wprowadzić luki w zabezpieczeniach, jeśli nie jest obsługiwana prawidłowo. Ponadto, gdy Access-Control-Allow-Credentials jest ustawione na true, Access-Control-Allow-Origin nie może być ustawione na "*". Musisz jawnie określić dozwolone źródło(a).
7. Regularnie przeglądaj i aktualizuj konfigurację CORS: W miarę rozwoju aplikacji regularnie przeglądaj i aktualizuj konfigurację CORS, aby upewnić się, że pozostaje bezpieczna i spełnia Twoje potrzeby.
8. Zrozum implikacje różnych konfiguracji CORS: Bądź świadomy implikacji bezpieczeństwa różnych konfiguracji CORS i wybierz tę, która jest odpowiednia dla Twojej aplikacji.
9. Testuj swoją implementację CORS: Dokładnie przetestuj swoją implementację CORS, aby upewnić się, że działa zgodnie z oczekiwaniami i nie wprowadza żadnych luk w zabezpieczeniach. Użyj narzędzi deweloperskich przeglądarki do inspekcji żądań i odpowiedzi sieciowych oraz zautomatyzowanych narzędzi testujących do weryfikacji zachowania CORS.

Przykład: Użycie Fetch API z CORS

Oto przykład, jak użyć API fetch do wysłania żądania między domenami:

fetch('https://api.example.com/data', {
  method: 'GET',
  mode: 'cors', // Informuje przeglądarkę, że to jest żądanie CORS
  headers: {
    'Content-Type': 'application/json',
    'X-Custom-Header': 'value'
  }
})
.then(response => {
  if (!response.ok) {
    throw new Error('Odpowiedź sieci nie była pomyślna');
  }
  return response.json();
})
.then(data => {
  console.log(data);
})
.catch(error => {
  console.error('Wystąpił problem z operacją fetch:', error);
});

Opcja mode: 'cors' informuje przeglądarkę, że jest to żądanie CORS. Jeśli serwer nie zezwoli na pochodzenie, przeglądarka zablokuje dostęp do odpowiedzi i zostanie rzucony błąd.

Jeśli używasz poświadczeń (np. plików cookie), musisz ustawić opcję credentials na 'include':

fetch('https://api.example.com/data', {
  method: 'GET',
  mode: 'cors',
  credentials: 'include', // Dołącz pliki cookie do żądania
  headers: {
    'Content-Type': 'application/json'
  }
})
.then(response => {
  // ...
});

CORS i JSONP

JSON with Padding (JSONP) to starsza technika omijania polityki tego samego pochodzenia. Działa poprzez dynamiczne tworzenie znacznika <script>, który ładuje dane z innej domeny. Chociaż JSONP może być użyteczny w pewnych sytuacjach, ma znaczne ograniczenia bezpieczeństwa i należy go unikać, gdy jest to możliwe. CORS jest preferowanym rozwiązaniem do komunikacji między domenami, ponieważ zapewnia bezpieczniejszy i bardziej elastyczny mechanizm.

Kluczowe różnice między CORS a JSONP:

• Bezpieczeństwo: CORS jest bezpieczniejszy niż JSONP, ponieważ pozwala serwerowi kontrolować, które źródła mają dostęp do jego zasobów. JSONP nie zapewnia żadnej kontroli pochodzenia.
• Metody HTTP: CORS obsługuje wszystkie metody HTTP (np. GET, POST, PUT, DELETE), podczas gdy JSONP obsługuje tylko żądania GET.
• Obsługa błędów: CORS zapewnia lepszą obsługę błędów niż JSONP. Gdy żądanie CORS zawiedzie, przeglądarka dostarcza szczegółowe komunikaty o błędach. Obsługa błędów w JSONP ogranicza się do wykrywania, czy skrypt załadował się pomyślnie.

Rozwiązywanie problemów z CORS

Problemy z CORS mogą być frustrujące do debugowania. Oto kilka typowych wskazówek dotyczących rozwiązywania problemów:

• Sprawdź konsolę przeglądarki: Konsola przeglądarki zazwyczaj dostarcza szczegółowych komunikatów o błędach dotyczących problemów z CORS.
• Sprawdź żądania sieciowe: Użyj narzędzi deweloperskich przeglądarki, aby sprawdzić nagłówki HTTP zarówno żądania, jak i odpowiedzi. Sprawdź, czy nagłówki Origin i Access-Control-Allow-Origin są ustawione poprawnie.
• Zweryfikuj konfigurację po stronie serwera: Sprawdź dokładnie swoją konfigurację CORS po stronie serwera, aby upewnić się, że zezwala na poprawne źródła, metody i nagłówki.
• Wyczyść pamięć podręczną przeglądarki: Czasami zbuforowane odpowiedzi preflight mogą powodować problemy z CORS. Spróbuj wyczyścić pamięć podręczną przeglądarki lub użyć okna przeglądania prywatnego.
• Użyj proxy CORS: W niektórych przypadkach może być konieczne użycie proxy CORS w celu ominięcia ograniczeń CORS. Bądź jednak świadomy, że używanie proxy CORS może wprowadzać ryzyko bezpieczeństwa.
• Sprawdź błędne konfiguracje: Szukaj typowych błędów konfiguracyjnych, takich jak brakujący nagłówek Access-Control-Allow-Origin, nieprawidłowe wartości Access-Control-Allow-Methods lub Access-Control-Allow-Headers, lub nieprawidłowy nagłówek Origin w żądaniu.

Podsumowanie

Cross-Origin Resource Sharing (CORS) to niezbędny mechanizm umożliwiający bezpieczną komunikację między różnymi źródłami w aplikacjach JavaScript. Dzięki zrozumieniu polityki tego samego pochodzenia, przepływu pracy CORS oraz różnych zaangażowanych nagłówków HTTP, deweloperzy mogą skutecznie wdrażać CORS, aby chronić swoje aplikacje przed lukami w zabezpieczeniach, jednocześnie zezwalając na legalne żądania między domenami. Stosowanie najlepszych praktyk w konfiguracji CORS i regularne przeglądanie implementacji są kluczowe dla utrzymania bezpiecznej i solidnej aplikacji internetowej.

Ten kompleksowy przewodnik stanowi solidną podstawę do zrozumienia i wdrożenia CORS. Pamiętaj, aby konsultować się z oficjalną dokumentacją i zasobami dla Twojej konkretnej technologii po stronie serwera, aby upewnić się, że wdrażasz CORS poprawnie i bezpiecznie.

Dalsze zasoby

• MDN Web Docs: Cross-Origin Resource Sharing (CORS)
• W3C: Cross-Origin Resource Sharing (CORS)
• PortSwigger Web Security Academy: CORS