Browsed by
Category: Http dla developerów

Zapytania warunkowe oparte na sumach kontrolnych

Zapytania warunkowe oparte na sumach kontrolnych

W tym przypadku stawiane warunki są oparte na pewnym kluczu dla zasobu. Powinien on być silnym walidatorem, a więc zmieniać się za każdym razem, gdy zasób ulegnie zmianie.

Definiuje się go za pomocą nagłówka ETag:

Response
Cache-Control:public, max-age=31536000
ETag: "15f0fff99ed5aae4edffdd6496d7131f"

Gdy klient chce ponownie pobrać dany zasób, informuje serwer o ETagu aktualnie przechowywanym w cache’u. Gdy ten się zmieni należy ponownie przesłać treść zasobu.

Request
If-None-Match: "15f0fff99ed5aae4edffdd6496d7131f"

W tym przypadku istnieją 3 użyteczne nagłówki:

  • If-Match – używane do warunkowego wykonywania zapytań modyfikujących dane dla upewnienia się, że rekord się nie zmienił,
  • If-None-Match – używane do warunkowego pobierania zasobu, gdy przechowujemy go już w cache (patrz przykład wyżej),
  • If-Range – pozwala pobrać pewien zakres zasobu (w połączeniu z nagłówkiem Range), jednak tylko gdy jego przechowywana wersja jest nadal aktualna. Ten nagówkek współpracuje zarówno z datą jak i ETagiem.

 

 

Nagłówki cache

Nagłówki cache

Age

W przypadku, gdy jako wynik zapytania jest zwracany zasób przechowywany w cache, nagłówek ten mówi nam, ile czasu (w sekundach) minęło od pobrania treści rekordu.

Cache-Control

Jest on stosowany do sterowania zachowaniem cache. Może posiadać niżej wymienione parametry:

max-age – wskazuje jak długi czas życia (w sekundach) przechowywanego zasobu jest akceptowalny; może być używany zarówno w zapytaniach jak i odpowiedziach. Ustawienie max-age: 0 powoduje, że zasób jest dynamiczny i nie podlega cache’owaniu. Jednak nie powinniśmy tego nadużywać, bo dla większości zasobów jest możliwe ustalenie pewnego okresu trwałości, choćby 10 sekund. Nawet dla zasobów, wymagających pełnej aktualności.

s-maxage – działa podobnie jak max-age, przy czym odwołuje się do współdzielonego cache’u.

max-stale – oznacza, że klient jest gotowy na odczytanie z cache’u zasobu, który jest nieaktualny przez maksymalną zdefiniowaną ilość sekund. Pozwala na zdefiniowanie dodatkowego czasu używania zasobu z cache.

min-fresh – pozwala pobrać wartość, która będzie jeszcze aktualna co najmniej przez określoną ilość sekund.

no-cache – informuje, że do wykonania tego zapytania nie powinien być wykorzystany cache.

no-store – informuje, że żaden fragment odpowiedzi nie powinien być zapisywany w cache.

no-transform – oznacza, że serwery pośrednie nie powinny przekształcać tej wiadomości. Nie powinny też próbować korzystać z cache dla tego rekordu, ani dodawać informacji o aktualności rekordu (Age). Dodatkowo niektóre serwery proxy mogą chcieć dokonywać transformacji przesyłanych treści, np. kompresji obrazów. Ta opcja zakazuje tego typu modyfikacji. Jest to przydatne do przesyłania danych wrażliwych, np. w czasie logowania.

only-if-cached – klient chce dostać tylko dane znajdujące się w cache’u. Odpowiedzią może być rekord pobrany z cache lub kod 504 (Gateway Timeout), gdy cache dla tego zasobu jest pusty.

must-revalidate – oznacza, że odkąd rekord w cache stanie się nieaktualny, nie może on już być więcej użyty. Jest to użyteczne do zapewnienia wiarygodnych operacji zgodnych z ustawieniami daty ważności. Służy zwykle do wymuszenia odświeżenia rekordu niezależnie od ustawień klienta.

public – oznacza, że request nie jest wrażliwy i może być przechowywany we współdzielonym cache’u.

private – zapytanie i odpowiedź mogą być tylko przechowywane i udostępniane w obrębie tego samego użytkownika. Nie zapewnia to jednak bezpieczeństwa przechowywanych danych i nadal informacje autentykacyjne nie powinny być cache’owane.

proxy-revalidate – działa tak samo jak must-revalidate, ale tylko dla współdzielonego cache’u.

Poniżej widać przypisanie, które opcje mogą być użyte w zapytaniach, a które w odpowiedziach.

Request Response
no-cache public
no-store private
max-age no-cache
max-stale no-store
min-fresh no-transform
no-transform must-revalidate
only-if-cached proxy-revalidate
max-age
s-maxage

cache-times
Przykłady:

Cache-Control:public, max-age=31536000
Powyższy nagłówek oznacza cache ważny rok czasu od momentu pobrania

Cache-Control:public
Expires: Mon, 25 Jun 2012 21:31:12 GMT

Ten nagłówek wskazuje dokładną datę wygaśnięcia cache’owanego elementu

Expires

Wskazuje datę i godzinę, po której odpowiedź jest traktowana jako zdezaktualizowana. Wartość max-age z nagłówka Cache-Control jest ważniejsza niż Expires i nadpisuje ją.

Pragma

Nagłówek ten służy głównie do zapewnienia wstecznej kompatybilności ze standardem HTTP 1.0. Pozwala na zdefiniowanie dodatkowych właściwości dla zapytania. W naszym przypadku interesująca jest tylko wartość no-cache, która działa identycznie jak no-cache z Cache-Control.

Należy zauważyć, że w przypadku wystąpienia nagłówka Cache-Control i przetwarzania zapytania w standardzie HTTP 1.1, nagłówek Pragma jest ignorowany.

Może to prowadzić sytuacji, że definiując dwa sprzeczne nagłówki, powodujemy różne zachowanie naszego zapytania zależnie od obsługującej go wersji HTTP. Należy o tym pamiętać podczas używania Pragma.

GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache

Warning

Nagłówek ten może przekazywać dodatkowe informacje na temat transformacji, jakim podlegała wiadomość. Jest to ostrzeżenie, że wiadomość wysłana różni się od otrzymanej.

Ostrzeżenia są podobne do statusów, jednak mogą przekazywać więcej informacji i mogą występować wielokrotnie w jednej wiadomości. Na przykład:

Warning: 110 - "Response is Stale"
Warning: 113 - "Heuristic Expiration"

Źródła:
http://www.mobify.com/blog/beginners-guide-to-http-cache-headers/
https://www.mnot.net/cache_docs/
https://tools.ietf.org/html/rfc7234

Sprawdzanie aktualności rekordu

Sprawdzanie aktualności rekordu

Gdy klient posiada dany zasób w cache’u, a następnie wykonuje zapytanie o ten sam zasób, konieczne jest sprawdzenie jego aktualności. Jest to wykonywane za pomocą zapytań warunkowych. Polegają one na wysłaniu pytania o zasób, jednak zasób ten zostanie przesłany z powrotem tylko w przypadku spełnienia określonych warunków.

W przypadku sprawdzania aktualności rekordu stosuje się dwa podejścia:

  • Sprawdzenie po dacie ważności zasobu
  • Sprawdzenie po „sumie kontrolnej” zasobu

Oba sposoby zostaną później szerzej omówione.

Serwer może odpowiedzieć na takie warunkowe zapytanie na następujące sposoby:

  • Może wysłać odpowiedź ze statusem 304 (Not modified) – nie powoduje to aktualizacji treści przechowywanego zasobu, a jedynie jego daty i daty ważności (jeżeli były one uwzględnione w odpowiedzi serwera). W tym przypadku treść nie jest ponownie przesyłana, jako wynik zapytania zwracana jest wersja znajdująca się w cache
  • Może wysłać odpowiedź ze statusem 200 (OK). Wymusza zaktualizowanie bieżącej przechowywanej zawartości i to właśnie ona jest używana
  • W przypadku zwrócenia informacji o błędzie (na przykład sieciowym) przez serwer, mechanizm cache może zarówno zwrócić komunikat błędu jak i użyć ostatnio zachowanej wartości, aby chwilowo ukryć wystąpienie błędu.

Metoda HEAD także pozwala sprawdzić aktualność danych w cache, jednak nie potrafi ona zaktualizować stanu obiektu (ponieważ nie jest on przesyłany), więc zostanie on pobrany dopiero, gdy wykonamy zapytanie GET.

W przypadku poprawnego wykonania metod nie oznaczonych jako bezpieczne (PUT, POST, DELETE) konieczna jest dezaktualizacja obiektów w cache posiadających ten sam adres i host.

 

Aktualność obiektu w cache

Aktualność obiektu w cache

Obiekt w cache możemy nazwać aktualnym, jeżeli nie minął jeszcze jego termin ważności. Czas ten jest liczony od momentu pobrania zasobu do momentu określonego przez nagłówki takie jak Expires lub Cache-Control. Jeżeli serwer chce spowodować unieważnienie zachowanego obiektu, powinien on wysłać datę ważności z przeszłości. Dzięki temu podczas najbliższego sprawdzania poprawności lub pobierania zawartości zasobu zostanie on bezwzględnie odświeżony (pobrany ponownie z serwera).

Do momentu aż minie czas ważności danego obiektu wszelkie żądania jego pobrania spowodują skorzystanie z zapamiętanej w cache wartości. Data użyta podczas definiowania czasu ważności, zawsze jest zapisana w strefie czasowej GMT lub UTC. Wskazuje na to skrót na końcu daty, który jest obowiązkowy. Przeciwdziała to problemom z niezgodnością stref czasowych serwera i klienta.

Czas życia może być ustalony za pomocą następujących nagłówków:

  1. dla współdzielonego cache’u używana jest dyrektywa s-max-age w Cache-Content
  2. dla zwykłego – max-age
  3. nagłówek Expires
  4. gdy żaden z wymienionych nagłówków nie wystąpi (czyli serwer w swojej odpowiedzi na zapytanie nie zdefiniuje czasu życia obiektu), zostanie użyta heurystyka do wyliczenia domniemanego czasu ważności

Heurystyczna metoda wyliczania czasu życia zależy od klienta (przeglądarki) z którego korzystamy, jednak często wykorzystuje ona obecność innych nagłówków, które mogą być wskazówką dla daty ważności całego zasobu. Możemy rozpoznać, że czas życia został obliczony, dzięki nagłówkowi:

Warning: 113 - "Heuristic Expiration"

W przypadku, gdy z jakichkolwiek powodów niemożliwe jest odświeżenie rekordu, przeglądarka może zwrócić nieaktualną wartość, dodając nagłówek:

Warning: 110 - "Response is Stale"
Nagłówek Age

Przekazuje informację o tym jak długo (w sekundach) obiekt będzie jeszcze aktualny w cache. Pole jest definiowane po stronie serwera, jednak klient przed użyciem go może dokonać pewnej modyfikacji wartości ze względu na opóźnienie sieciowe.

Cache HTTP

Cache HTTP

Główną metodą pracy z użyciem HTTP jest pobieranie oraz zapisywanie zasobów z serwera. Najczęściej odczytujemy informacje, jednak z tym może wiązać się pewien problem. Pobieranie treści z serwera zawsze trwa pewien czas, w szczególności, jeżeli potrzebne jest przesłanie dużej ilości informacji. Może to powodować problemy z wydajnością zarówno ze strony klienta jak i serwera.
Klient musi pobierać wiele różnych informacji, aby je wykorzystać (np. zaprezentować). Z kolei serwer w przypadku podłączenia się do niego wielu klientów, może mieć problem z przepustowością łącz sieciowych. Nadmiarowy transfer jest także dodatkowym kosztem dla właścicieli serwerów, ponieważ część z nich jest rozliczana za gigabajty wykorzystanego transferu.
Warto zauważyć, że niektóre dane potrzebujemy pobierać wielokrotnie. Dobrym przykładem może tu być kod skryptu jQuery pobierany podczas każdego ładowania strony, która z niego korzysta. W wielu przypadkach zasób taki jest rzadko modyfikowany, więc nie musimy go za każdym razem pobierać z serwera. To jest sposób na zmniejszenie obciążenia sieci oraz skrócenie czasu przetwarzania zarówno po stronie klienta jak i serwera.
Cache HTTP jest to mechanizm lokalnego przechowywania wyników zapytań w celu ich późniejszego wykorzystania bez potrzeby ponownego pytania serwera. Mechanizm ten zarządza również kasowaniem przechowywanych odpowiedzi, które się zestarzały, oraz ich aktualizowaniem.
Przechowywana odpowiedź jest uznawana za aktualną, jeżeli może ona być wykorzystana bez ponownej walidacji zasobu.

Cache-not used

Każdy rekord przechowywany w cache jest identyfikowany na podstawie klucza. Odpowiada on parametrom wywołania, dla którego zapamiętana jest odpowiedź. Możliwe jest zachowywanie pełnych odpowiedzi, ale również przekierowań, informacji o błędach oraz częściowych odpowiedzi.
W przypadku korzystania z funkcjonalności negocjowania typu zawartości, może być przechowywane wiele wersji dla jednego zasobu, na przykład dla różnego typu lub języka.
Cache’owaniu mogą podlegać następujące metody:

  • GET,
  • POST – tylko przy użyciu nagłówków Cache-Control lub Expires,
  • HEAD – może być wykorzystywany do sprawdzania aktualności zachowanych obiektów.

W przypadku korzystania z zapytań typu GET w niektórych przypadkach potrzebne jest spełnienie dodatkowych warunków:

  • dla częściowych odpowiedzi wymagana jest obsługa nagłówków Range oraz Content-Range,
  • zapytania zawierające informacje autoryzacyjne (nagłówek Authorization) nie mogą być przechowywane.

Powyżej przedstawione zostały ogólne zasady działania mechanizmu cache. Konkretnymi zaś jego aspektami zajmiemy się później.

Metoda CONNECT

Metoda CONNECT

Za pomocą tego zapytania można połączyć się do serwera pośredniego w drodze do serwera docelowego. Jest to niezbędne, gdy dwa węzły nie są bezpośrednio ze sobą powiązane (np. istnieje zapora sieciowa). Stwarza to wrażenie bezpośredniego połączenia. Często są one wykorzystywane do tworzenia połączenia pomiędzy adresami, które są połączone poprzez jedno lub wiele proxy. Taka komunikacja może być zabezpieczona za pomocą TLS (metoda szyfrowania połączenia).
Wysyłając zapytanie CONNECT należy tylko przekazać docelowy adres, do którego chcemy się połączyć.

CONNECT example.com:80 HTTP/1.1
 Host: example.com:80

Serwer proxy, który odbierze to zapytanie, może wykonać kolejne zapytanie CONNECT, łącząc się do kolejnego proxy i tworząc w ten sposób łańcuch połączeń. Po ustanowieniu połączenia, zwracany jest status 200 (OK), zaś status 400 (Bad request) zwracany jest wtedy, gdy serwer nie obsługuje funkcji serwera proxy. Od momentu otrzymania rezultatu o powodzeniu operacji, pośrednie serwery proxy zmieniają tryb pracy na tunelowanie przechodzących wiadomości. W przypadku zamknięcia połączenia w jakimkolwiek serwerze biorącym udział w operacji, cały tunel powinien zostać zamknięty.

Możliwa jest także autoryzacja przy korzystaniu z proxy. Należy do tego celu użyć nagłówka Proxy-Authorization

CONNECT server.example.com:80 HTTP/1.1
 Host: server.example.com:80
 Proxy-Authorization: basic aGVsbG86d29ybGQ=

Istnieje niebezpieczeństwo niepoprawnego działania tunelowanego połączenia, gdy skorzystamy z powszechnie używanych portów do innych celów niż standardowo przyjęte. Dla przykładu, gdy używamy portu 25 standardowo przypisanego obsłudze SMTP, serwer może odrzucać część naszej komunikacji jako spam emailowy. Z uwagi na to serwery proxy powinny używać zdefiniowanego zakresu portów, aby nie powodować tego typu kolizji.

Metoda TRACE

Metoda TRACE

Metoda ta jest używana do zdalnego śledzenia wywołań wszelkich innych metod HTTP. Zapytanie powinno odwzorowywać badaną wiadomość z wyłączeniem pewnych wrażliwych pól (np. autoryzacyjnych).

Odpowiedź powinna:

  • mieć typ: message/http,
  • odesłać z powrotem niezmienione, wszystkie nagłówki zapytania,
  • nie odsyłać treści wiadomości
  • dodać nagłówek diagnostyczny.

Wiadomość ta może zostać wysłana zarówno do adresata, jak i serwerów pośrednich (np. proxy). Z tego też powodu, nie powinny być za jej pośrednictwem przesyłane żadne wrażliwe informacje w nagłówkach zapytania (takiej jak ciasteczka lub dane autoryzacyjne).
TRACE umożliwia prześledzenie ciągu przekazywania zapytania. Używany jest do tego nagłówek Via. Są w nim zapisane dane serwera, który bezpośrednio odesłał odpowiedź w ciągu informacyjnym. Wiele pól w nagłówku Via pokazuje ścieżkę którą przebyła wiadomość. Zazwyczaj przez serwery proxy. Dodatkowo przy każdej nazwie serwera widać wersję protokołu HTTP.

Via: 1.0 fred, 1.1 p.example.net

Użycie nagłówka Max-Forwards pozwala klientowi przez ile serwerów proxy chcemy przesłać wiadomość. Kiedy, liczba serwerów proxy będzie większa, zostanie zwrócony błąd.

Request Response
TRACE / HTTP/1.1
Host:www.apache.org
X-Header: Test
HTTP/1.1 200 OK
Date: Wed, 09 Jun 2010 16:14:49 GMT
Server: Apache/2.2.12 (Unix)
Transfer-Encoding: chunked
Content-Type: message/http
TRACE / HTTP/1.1
Host: http://www.apache.org
X-Header: Test

Cross Site Tracing

Jednym z bardziej wartościowych zasobów dla atakujących podczas pracy ze stronami www są ciasteczka. Często przechowują one wrażliwe dane takie jak identyfikator sesji użytkownika, nazwę jego konta lub informacje uwierzytelniające. Dysponując takimi danymi intruz może próbować podszyć się pod użytkownika naszej strony.

Aby temu przeciwdziałać wprowadzono opcję httpOnly dla ciasteczek. Powoduje ona, że niemożliwe jest odczytanie wartości ciasteczek z poziomu JavaScript. Jest to zabezpieczenie przed atakami XSS. Jednak w 2003 roku Jeramiah Grossman odkrył jak obejść to zabezpieczenie stosując metodę TRACE. Z uwagi na specyfikę tej metody, a mianowicie fakt, że odsyła ona w swojej treści całą wysłaną wiadomość, można wykonać zapytanie TRACE do serwera aplikacji. Zostaną do niego automatycznie dodane ciasteczka dostępne dla strony, a w rezultacie powrócą one wraz z odpowiedzią, co spowoduje ich ujawnienie osobie atakującej.

function sendTrace () 
{ 
   var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP"); 
   xmlHttp.open("TRACE", "http://foo.bar",false); 
   xmlHttp.send(); 
   xmlDoc=xmlHttp.responseText; 
   alert(xmlDoc); 
}

Z tego powodu w tej chwili zalecane jest wyłączenie tej metody na serwerach produkcyjnych.

Źródła:
http://tools.ietf.org/html/rfc7231
http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
https://www.owasp.org/index.php/Cross_Site_Tracing

Metoda DELETE

Metoda DELETE

Metoda DELETE oznacza żądanie skasowania adresu URL, do którego odwołujemy się w zapytaniu. Nie musi to oznaczać skasowania zasobu (choć może), ale musi się wiązać z dezaktywacją adresu URL do niego prowadzącego. Zasób nie musi być kasowany, gdy jest wskazywany również przez inne adresy.
Metoda DELETE jest najczęściej używana w połączeniu z PUT z uwagi na to, że operują one na unikalnym adresie, który identyfikuje używany przez nas zasób.

DELETEJeżeli operacja kasowania odnośnika powiedzie się, powinien zostać zwrócony rezultat

  • 202 (Accepted), gdy zasób nie został skasowany,
  • 204 (No content), jeżeli został on skasowany i operacja nie zwróciła żadnej wartości,
  • 200 (OK), gdy zasób został skasowany i zwrócono wynik operacji.
Request Response
DELETE /articles/red-shoe HTTP/1.1 
Host: www.example.com
HTTP/1.1 204 No Content
Metoda PUT

Metoda PUT

Metoda PUT służy do zachowania obiektu przekazywanego w treści zapytania pod wskazanym adresem URL.

  • W przypadku gdy pod tym adresem istniał już zasób, powinien on zostać nadpisany. Zwracany jest wtedy rezultat 200 (OK) lub 204 (No Content), gdy nastąpiło nadpisanie pustym zbiorem.
  • Jeżeli zasób nie istniał, to powinien zostać utworzony pod podanym adresem. Zwracany jest wtedy rezultat 201 (Created)
    PUT /article/1234 HTTP/1.1
PUT /article/1234 HTTP/1.1
{ "color": "red" }

Gdy metoda PUT zakończy się powodzeniem, wykonanie metody GET dla tego samego adresu powinno zwrócić dokładnie ten sam obiekt jaki był użyty w PUT. Oczywiście tylko wtedy, gdy zasób ten nie został zmodyfikowany w międzyczasie. Warto też wspomnieć, że metoda PUT jest idempotentna, a więc wielokrotne jej wykonanie powinno przynieść identyczny rezultat.

PUTFormat treści zapytania PUT powinien być zgodny z typem wiadomości zwracanej przez metodę GET. W odpowiedzi serwer może wysłać nagłówki walidacyjne takie jak ETag i Last-Modified, jeżeli wartość zasobu jest identyczna z wartością wysłaną. PUT może także modyfikować dodatkowe zasoby poza wskazanym adresem, aby na przykład uaktualnić relacje między zasobami.

Różnice pomiędzy PUT i POST

Istnieje kilka podstawowych różnic pomiędzy tymi dwoma metodami:

  • Treść zapytania POST może mieć dowolna formę, którą serwer potrafi zinterpretować, podczas gdy w metodzie PUT treść powinna być taka sama jak treść modyfikowanego zasobu.
  • Metoda PUT jest idempotentna, ponieważ dotyczy tylko zasobu o konkretnym adresie, a POST może tworzyć zasoby pod kolejnymi adresami.
  • PUT zakłada znajomość docelowego adresu zasobu, co jest niemożliwe w przypadku wstawiania rekordu, dla którego zostanie wygenerowany numer id. Natomiast w metodzie POST nie podajemy adresu, gdyż jest on generowany po stworzeniu danego zasobu (patrz przykład poniżej).
Request Response
PUT /articles/red-shoe HTTP/1.1
 { name: "shoe", color: "red" }
HTTP/1.1 201 Created
 Location: /articles/red-shoe
Request Response
POST /articles HTTP/1.1
 { name: "shoe", color: "red" }
HTTP/1.1 201 Created
 Location: /articles/63636

Źródła:
http://tools.ietf.org/html/rfc7231#section-4.3.4

Metoda HEAD

Metoda HEAD

Metoda HEAD działa tak samo jak metoda GET. Nie zwraca ona jednak treści wiadomości, a jedynie nagłówki. Powinny one być identyczne z tymi zwracanymi przez metodę GET o takich samych parametrach.

HEADJedynym wyjątkiem są nagłówki mówiące o treści wiadomości takie jak: Content-Length, Content-Range, które mogą nie wystąpić w odpowiedzi w metodzie HEAD.

Metoda GET

Request Response
GET /admin HTTP/1.1
Host: www.example.com
HTTP/1.1 200 OK
Date: Mon, 18 Aug 2012 22:44:11 GMT
Content-Type: text/html
Content-Length: 123<html>

</html>

Metoda HEAD

Request Response
HEAD /admin HTTP/1.1
Host: www.example.com
HTTP/1.1 200 OK
Date: Mon, 18 Aug 2012 22:44:11 GMT
Content-Type: text/html

Omawiana metoda być użyta do pozyskiwania informacji na temat zasobu bez jego przesyłania. Na przykład do sprawdzenia poprawności linków, daty ostatniej modyfikacji i tym podobnych informacji, które możemy odczytać z nagłówków. Zapytania HEAD mogą brać udział w cache’owaniu. Mianowicie zapytanie tego typu może skutkować oznaczeniem przechowywanego zasobu jako starego i wymagającego ponownego pobrania, ale nie może go zaktualizować (ponieważ sam zasób nie jest przesyłany).

RyzykO związane z zapytaniami HEAD

Generalnie HEAD nie jest rozpatrywane jako potencjalne źródło zagrożeń. Jednak w źle zaprojektowanych systemach istnieje ryzyko wykorzystania tej metody do obejścia zabezpieczeń związanych z logowaniem do systemu.

Aby pokazać działanie tego obejścia zabezpieczeń, posłużymy się przykładem zasobu, którego pobranie wymaga logowania. W tym przypadku przy próbie dostępu do zasobu następuje przekierowanie do strony z możliwością logowania do systemu. Zakładamy, że strona zapamiętuje informacje o statusie zalogowania w ciasteczkach.

Dla takiego zasobu po wykonaniu zapytania GET, zwracane jest przekierowanie do strony logowania. Jednak w przypadku niepoprawnej implementacji metody HEAD, wysłanie zapytania HEAD na ten sam adres url, spowoduje otrzymanie wyniku pozytywnego i nagłówków uzupełniających pliki ciasteczek. Dzięki temu zapamiętane zostaną informacje uwierzytelniające i kolejne wywołanie GET nie będzie już wymagało logowania. Dlatego należy zawsze pamiętać, żeby wywołanie HEAD zachowywało się identycznie jak w przypadku zapytania GET. Także w przypadku autoryzacji dostępu do zasobów.