W terminologii HTTP działa jako serwer źródłowy na połączeniu od strony klienta, tłumacząc żądanie do dostawy przychodzącej. Klienci zwykle adresują reverse proxy zamiast wybierać je jako przekaźnik ogólnego zastosowania.
Reverse proxy często wykonuje terminację TLS, routing żądań, dystrybucję obciążenia, buforowanie, integrację uwierzytelniania, ograniczanie tempa i kontrolowaną publikację usług wewnętrznych. Poprawny projekt ogranicza też bezpośredni dostęp do backendu i definiuje, którym dodawanym przez proxy nagłówkom aplikacja może ufać. Publiczna nazwa proxy, certyfikaty, kontrole kondycji i zachowanie awaryjne stają się częścią architektury usługi.
Najważniejsze punkty
Routing i izolacjaKieruj jedynie oczekiwane hosty, ścieżki, metody i protokoły. Umieszczaj backendy w kontrolowanych sieciach i zapobiegaj omijaniu proxy przez klientów internetowych w celu bezpośredniego dotarcia do źródła.
Tożsamość i metadaneUsuwaj niezaufane nagłówki przekazujące przed dodaniem autorytatywnych wartości. Aplikacje powinny ufać im tylko z wyznaczonych adresów proxy i zachowywać podlegającą audytowi atrybucję klienta.
Dostępność i prywatnośćUżywaj ograniczonych limitów czasu, limitów rozmiaru żądań, kontroli kondycji, kontroli pojemności i odpornych instancji. Minimalizuj logi i chroń tokeny sesji, nagłówki autoryzacji i zdeszyfrowaną treść.
Istotne ograniczenieReverse proxy nie czyni automatycznie aplikacji bezpieczną i nie jest synonimem zapory aplikacji webowych. Niebezpieczna logika aplikacji, pobłażliwe trasy, obejście źródła, pomylenie nagłówków lub kompromitacja proxy mogą nadal eksponować usługę. Terminacja TLS pozostawia też proxy obsługujące tekst jawny i może wymagać chronionego ponownego szyfrowania do backendów.