În terminologia HTTP, acționează ca un server origin pe conexiunea orientată către client, în timp ce traduce cererea pentru livrarea internă. Clienții se adresează în mod normal reverse proxy-ului, în loc să îl selecteze ca releu de uz general.
Reverse proxy-urile realizează în mod obișnuit terminarea TLS, dirijarea cererilor, distribuția încărcăturii, caching, integrarea autentificării, limitarea ratei și publicarea controlată a serviciilor interne. Un design corect restricționează și accesul direct la backend și definește ce anteturi adăugate de proxy poate avea o aplicație încredere. Numele public al proxy-ului, certificatele, verificările de sănătate și comportamentul la eșec devin parte a arhitecturii serviciului.
Puncte esențiale
Dirijare și izolareDirijați doar gazde, căi, metode și protocoale așteptate. Plasați backend-urile pe rețele controlate și împiedicați clienții de pe internet să ocolească proxy-ul pentru a ajunge direct la un origin.
Identitate și metadateEliminați anteturile de forwardare nesigure înainte de a adăuga valori autoritative. Aplicațiile trebuie să aibă încredere în ele doar de la adrese de proxy desemnate și trebuie să păstreze o atribuire auditabilă a clientului.
Disponibilitate și confidențialitateFolosiți timeout-uri limitate, limite de dimensiune a cererilor, verificări de sănătate, controale de capacitate și instanțe reziliente. Minimizați jurnalele și protejați tokenurile de sesiune, anteturile de autorizare și conținutul decriptat.
Limitare importantăUn reverse proxy nu face automat o aplicație sigură și nu este sinonim cu un firewall pentru aplicații web. Logica de aplicație nesigură, rute permisive, ocolirea origin-ului, confuzia de anteturi sau compromiterea proxy-ului pot totuși expune serviciul. Terminarea TLS lasă și proxy-ul manipulând text în clar și poate cere recriptare protejată către backend-uri.