Wysyłanie niewrażliwych danych - powinno używać się metody get czy post?

Jeśli mam zamiar przesłać niedużą ilość niewrażliwych danych to lepiej użyć metody GET czy POST ?

Wiem, że GET nie powinno się używać do wysyłania dużej ilości danych lub wrażliwych danych, ponieważ dane, które wysyłamy są widoczne wtedy w adresie url.

Tylko się zastanawiam co jeśli chce przesłać nieduża ilość niewrażliwych danych. Lepszą opcją jest wtedy metoda GET czy POST ?

ponieważ dane, które wysyłamy są widoczne wtedy w adresie url To nie prawda. GET tak samo jak i POST może zwracać jsona i nie musi być nic w linku. IMO jeśli są to dane do odczytu, to użyłbym GET.

ledi12 napisał(a):

GET tak samo jak i POST może zwracać jsona i nie musi być nic w linku.

OP chyba pisze o wysyłaniu danych z przeglądarki na serwer.

Dobrze rozumiem, @puchatek11 ?

A mea culpa, nie doczytałem :) No jak chodzi o wysyłkę to faktycznie POST wydaję się sensowniejsze.

Tak, chodzi o wysyłkę danych na serwer.

Post

POST, ale nie dlatego że wrażliwe czy niewrażliwe *)

Dlatego, że wysyłanie z przeglądrki się robi np POST-em (lub innymi) a GET-em sie odbiera.

*) rzuć w cholerę to żródło. To jasiowe myślenie na poziomie 1995

puchatek11 napisał(a):

Jeśli mam zamiar przesłać niedużą ilość niewrażliwych danych to lepiej użyć metody GET czy POST ?

Wiem, że GET nie powinno się używać do wysyłania dużej ilości danych lub wrażliwych danych, ponieważ dane, które wysyłamy są widoczne wtedy w adresie url.

Tylko się zastanawiam co jeśli chce przesłać nieduża ilość niewrażliwych danych. Lepszą opcją jest wtedy metoda GET czy POST ?

Pod względem tego jak "wrażliwe" są dane, to nie ma to żadnego znaczenia. Request HTTP to request, nie różni się praktycznie niczym, oprócz słowa GET/POST w nagłówku i tego czy ma body czy nie.

ZrobieDobrze napisał(a):

Dlatego, że wysyłanie z przeglądrki się robi np POST-em (lub innymi) a GET-em sie odbiera.

*) rzuć w cholerę to żródło. To jasiowe myślenie na poziomie 1995

Brednie Nie prawda, bo po pierwsze GET'em też możesz wysłać dane, np w nagłówku lub w query params; i postem też możesz odebrać dane, np w response body. Więc obiema metodami da się zarówno wysyłać i odbierać dane, różnica jest tylko w formie.

Jak sprecyzujesz dokładnie co znaczy "się robi", to zrozumiesz że to jest jakby preferencja, a nie faktyczna cecha HTTP.

Innymi słowy - jeśli coś da się wykraść z GET'a, to tak samo łatwo to wykraść z POST'a. Więc pod względem bezpieczeństwa - nie ma różnicy.

Riddle napisał(a):

Pod względem tego jak "wrażliwe" są dane, to nie ma to żadnego znaczenia.

Ma znaczenie chociażby z tego powodu, że query string jest częścią URL, a URLe są rutynowo utrwalane w różnych miejscach: w historii przeglądarki, w różnych cache, w logach serwerów proxy, itd.

Innymi słowy - jeśli coś da się wykraść z GET'a, to tak samo łatwo to wykraść z POST'a. Więc pod względem bezpieczeństwa - nie ma różnicy.

XD

Alley Cat napisał(a):

Riddle napisał(a):

Pod względem tego jak "wrażliwe" są dane, to nie ma to żadnego znaczenia.

Ma znaczenie chociażby z tego powodu, że query string jest częścią URL, a URLe są rutynowo utrwalane w różnych miejscach: w historii przeglądarki, w różnych cache, w logach serwerów proxy, itd.

Jeśli coś jest w stanie utrwalić URL GET'a, to równie dobrze może utrwalić body POST'a. To czy to robi czy nie jest kwestią konfiguracji/implementacji tego narzędzia.

Innymi słowy - jeśli coś da się wykraść z GET'a, to tak samo łatwo to wykraść z POST'a. Więc pod względem bezpieczeństwa - nie ma różnicy.

XD

Nie mówię że powinno się wysyłać wrażliwe dane w query, w ulru, w headereach czy w body - to już zależy co chcesz osiągnąć, ale pod względem tego jaka to metoda to POST/GET są właściwie takie same.

Poza tym, jeśli coś jest w stanie podglądnąć URL requestu, to jest w stanie podglądnąć też body. Więc użycie POST będzie tylko pozornie bardziej bezpieczne. Wylicz wszystkie miejsca gdzie używając GET'a możesz się narazić na wyciech danych - wszystkie te miejsca również są podatne na wyciek dla POST.

Riddle napisał(a):

Poza tym, jeśli coś jest w stanie podglądnąć URL requestu, to jest w stanie podglądnąć też body. Więc użycie POST będzie tylko pozornie bardziej bezpieczne. Wylicz wszystkie miejsca gdzie używając GET'a możesz się narazić na wyciech danych - wszystkie te miejsca również są podatne na wyciek dla POST.

Nie jest tak, jak piszesz.

Wystarczy, że pracodawca będzie robił inspekcję TLS na FortiGate lub innym podobnym tanim gniocie, którego kiedyś zapomni zaktualizować i klops, bo całe logi ruchu webowego razem z query stringami będą dostępne dla każdego zainteresowanego i będzie smutek :(

Nie wspominając już o tego rodzaju "kwiatkach": https://sec-consult.com/vulnerability-lab/advisory/weak-encryption-cipher-and-hardcoded-cryptographic-keys-in-fortinet-products/

Samo wysłanie niewrażliwych danych przez GET nie jest problemem. Pytanie co się z nimi dalej dzieje. Poczytaj czym jest atak CSRF

Riddle napisał(a):

ZrobieDobrze napisał(a):

Dlatego, że wysyłanie z przeglądrki się robi np POST-em (lub innymi) a GET-em sie odbiera.

*) rzuć w cholerę to żródło. To jasiowe myślenie na poziomie 1995

Brednie, bo po pierwsze GET'em też możesz wysłać dane, np w nagłówku lub w query params; i postem też możesz odebrać dane, np w response body. Więc obiema metodami da się zarówno wysyłać i odbierać dane, różnica jest tylko w formie.

Jak sprecyzujesz dokładnie co znaczy "się robi", to zrozumiesz że to jest jakby preferencja, a nie faktyczna cecha HTTP.

Zanim zarzucisz (w kontekscie pytania poczatkujacego) komuś brednie naświetl pytającemu jak się ustawia serwery http, cache, ile razy może się zrealizować jedna operacja itd... jakie obowiazują zasady / konwencja co do podanych słow HTTP

ZrobieDobrze napisał(a):

Riddle napisał(a):

ZrobieDobrze napisał(a):

Dlatego, że wysyłanie z przeglądrki się robi np POST-em (lub innymi) a GET-em sie odbiera.

*) rzuć w cholerę to żródło. To jasiowe myślenie na poziomie 1995

Brednie, bo po pierwsze GET'em też możesz wysłać dane, np w nagłówku lub w query params; i postem też możesz odebrać dane, np w response body. Więc obiema metodami da się zarówno wysyłać i odbierać dane, różnica jest tylko w formie.

Jak sprecyzujesz dokładnie co znaczy "się robi", to zrozumiesz że to jest jakby preferencja, a nie faktyczna cecha HTTP.

Zanim zarzucisz (w kontekscie pytania poczatkujacego) komuś brednie naświetl pytającemu jak się ustawia serwery http, cache, ile razy może się zrealizować jedna operacja itd... jakie obowiazują zasady / konwencja co do podanych słow HTTP

Cały zamysł mojej odpowiedzi, dotyczył tego, że umieszczając dane w POST, wcale nie sprawimy że te dane będą jakkolwiek "bardziej bezpieczne". Obie te rzeczy są zwykłymi requestami HTTP, obie są przekazywane przez przeglądarkę, sieć, server i analizowane przez aplikacje backendową. Owszem, są pewne konwencje i domyślne ustawienia które w tych czy innych przypadkach traktują te żądania inaczej; ale ostatecznie pod względem komunikacji między serverem a klientem to to jest to samo. Jeśli na drodze między serverem a klientem jest coś co może podglądnąć ten request, to tak samo POST jak i GET jest na to podatny. Nie dawajmy pytającemu złudnego wrażenia że może "ochronić swoje dane" zmieniając metodę HTTP.

Robiąc krok wstecz - jeśli ktoś faktycznie jest zainteresowany bezpieczeństwem swoich danych, to raczej nie wyborem metody HTTP powinien być zainteresowany, ale prawdziwymi narzędziami przeznaczonymi do tego celu.

Co do tego że określiłem to co napisałeś słowem "brednie", chodziło o Twoją wypowiedź "POST'em się wysyła, GET'em się odbiera". Tak jak rozumiem czemu ktoś mógłby tak to określić, tak to jest tożsama sytuacja co określenie "Nożem się kroi, a widelcem się nabija". Rozumiem, czemu ktoś by tak powiedział, ale niestety prawdą jest że widelcem też można coś przekroić, a nożem też można coś nabić; podobnie jak mimo że "POST'em się wysyła, GET'em się odbiera" tak można wysłać dane GET'em i odebrać POST'em - to miałem na myśli mówiąć "brednie", być może lepiej byłoby użyć słowa "prawdziwe inaczej".

Żeby zakończyć tę debatę, czytając wiadomości, widzę że sporo odpowiadających ma opinie, że odpowiedź na pytanie w wątku brzmi "Lepiej użyć GET, niż POST" - i ja się z tym całkowicie zgadzam, do celu który autor ma, GET jest lepszy niż POST, także pełna zgoda. Ale czy powiem że "POST jest bezpieczniejszy niż GET"? No tego nie mogę powiedzieć, bo nie jest.

Kierując się już bezpośrednio do autora, @puchatek11 - wybierz metodę według konwencji, np Rest; ale nie wpadnij w fałszywe przekonanie że zmiana metody może Cię przed czymś uchronić. Jeśli jesteś zainteresowany bezpieczeństwem to są do tego inne metody i narzędzia.

Riddle napisał(a):

Cały zamysł mojej odpowiedzi, dotyczył tego, że umieszczając dane w POST, wcale nie sprawimy że te dane będą jakkolwiek "bardziej bezpieczne". Obie te rzeczy są zwykłymi requestami HTTP, obie są przekazywane przez przeglądarkę, sieć, server i analizowane przez aplikacje backendową. Owszem, są pewne konwencje i domyślne ustawienia które w tych czy innych przypadkach traktują te żądania inaczej; ale ostatecznie pod względem komunikacji między serverem a klientem to to jest to samo.

Co za brednie! Kolega chyba nie zdaje sobie sprawy, że podczas normalnej pracy przeglądarki adresy URL razem z ewentualnymi parametrami są rozsiewane po całym świecie, i nie mam na myśli jedynie serwerów docelowych.

Robiąc krok wstecz - jeśli ktoś faktycznie jest zainteresowany bezpieczeństwem swoich danych, to raczej nie wyborem metody HTTP powinien być zainteresowany, ale prawdziwymi narzędziami przeznaczonymi do tego celu.

A więc możemy sobie przekazywać dane jak chcemy, bo mamy WAF i TLS?

Czyżby o defense in depth kolega nie słyszał?

Alley Cat napisał(a):

Riddle napisał(a):

Cały zamysł mojej odpowiedzi, dotyczył tego, że umieszczając dane w POST, wcale nie sprawimy że te dane będą jakkolwiek "bardziej bezpieczne". Obie te rzeczy są zwykłymi requestami HTTP, obie są przekazywane przez przeglądarkę, sieć, server i analizowane przez aplikacje backendową. Owszem, są pewne konwencje i domyślne ustawienia które w tych czy innych przypadkach traktują te żądania inaczej; ale ostatecznie pod względem komunikacji między serverem a klientem to to jest to samo.

Co za brednie! Kolega chyba nie zdaje sobie sprawy, że podczas normalnej pracy przeglądarki adresy URL razem z ewentualnymi parametrami są rozsiewane po całym świecie, i nie mam na myśli jedynie serwerów docelowych.

Robiąc krok wstecz - jeśli ktoś faktycznie jest zainteresowany bezpieczeństwem swoich danych, to raczej nie wyborem metody HTTP powinien być zainteresowany, ale prawdziwymi narzędziami przeznaczonymi do tego celu.

A więc możemy sobie przekazywać dane jak chcemy, bo mamy WAF i TLS?

Czyżby o defense in depth kolega słyszał?

Wszystko to jest prawda.

Ale sama zmiana metody z GET na POST nas nie uchroni za bardzo przed tym.

Generalnie konwencja jest taka, że jak Twój request powoduje zapisanie czegoś na serwerze to używa się POST a jak nie to GET.
Czyli np. w GET możesz przekazać parametry do search, bo to powoduje tylko wyszukanie czegoś w bazie danych
A np. POST możesz użyć do stworzenia nowego konta albo np. komentarza.

Dodatkowo czasem POST można użyć jeśli mam bardzo dużo danych i nie chcemy ich przekazywać przez GET.

GET przydaje się też jeśli chcemy aby użytkownik mógł zapisać sobie dany link (np. do konkretnego wyszukania)

Riddle napisał(a):

Ale sama zmiana metody z GET na POST nas nie uchroni za bardzo przed tym.

Za to złe przekazywanie "wrażliwych" danych (np. w query stringu) stwarza całą masę różnych problemów, i właśnie o to tutaj chodzi: o przekazywanie danych w parametrach w URL vs przekazywanie danych w payloadzie POST - nie o samą zmianę GET na POST.

Alley Cat napisał(a):

Riddle napisał(a):

Ale sama zmiana metody z GET na POST nas nie uchroni za bardzo przed tym.

Za to złe przekazywanie "wrażliwych" danych (np. w query stringu) stwarza całą masę różnych problemów, i właśnie o to tutaj chodzi: o przekazywanie danych w parametrach w URL vs przekazywanie danych w payloadzie POST - nie o samą zmianę GET na POST.

No to ja się jak najbardziej zgadzam że przekazywanie danych w query params (w parametrach URL) jest słabym podejściem. Ale czym innym jest pytanie "Czy przekazywać parametry w query params czy nie?" względem pytania "Czy przekazywać dane GET czy POST". Na pierwsze z tych pytań odpowiedź brzmi: tak; na drugie nie. W takim POST również możesz przesłać parametry w query params.

Autor wątku nie zadał pytania "Czy przekazywać dane w query params czy w body", tylko zadał pytanie "Czy przekazywać je metodą POST czy GET".

Gdyby pytanie brzmiało "Czy przekazać parametry w query params", to jasne że odpowiedź brzmiałaby "nie". Ale nie tak brzmi pytanie, pytanie brzmi o wybór metody - a sama metoda nie ma znaczenia.

Nie ma znaczenia czy wyślesz taki request

GET http://my-serivce.com/index.php?token=very-secret

czy

POST http://my-serivce.com/index.php?token=very-secret

Riddle napisał(a):

Nie ma znaczenia czy wyślesz taki request

GET http://my-serivce.com/index.php?token=very-secret

czy

POST http://my-serivce.com/index.php?token=very-secret

No to wysyłaj secret token w CIELE żądania POST a nie w query stringu.

Gdyby pytanie brzmiało "Czy przekazać parametry w query params", to jasne że odpowiedź brzmiałaby "nie". Ale nie tak brzmi pytanie, pytanie brzmi o wybór metody - a sama metoda nie ma znaczenia.

Ma znaczenie, ponieważ GET wymusza wysłanie tego w URLu. POST nie wymsuza.

anonimowy napisał(a):

Generalnie konwencja jest taka, że jak Twój request powoduje zapisanie czegoś na serwerze to używa się POST a jak nie to GET.
Czyli np. w GET możesz przekazać parametry do search, bo to powoduje tylko wyszukanie czegoś w bazie danych
A np. POST możesz użyć do stworzenia nowego konta albo np. komentarza.

To ejst nie tylko konwencja, ale i specyfikacja. RFC9110

A zresztą wynika to z samych nazw metod: GET czyli WEŹ, POST czyli WYŚLIJ.

Żeby nie być gołosłownym. RFC9110 głosi, co następuje:

The GET method requests transfer of a current selected representation for the target resource. A successful response reflects the quality of "sameness" identified by the target URI (Section 1.2.2 of [URI]). Hence, retrieving identifiable information via HTTP is usually performed by making a GET request on an identifier associated with the potential for providing that information in a 200 (OK) response. GET is the primary mechanism of information retrieval ...

I dalej:

When information retrieval is performed with a mechanism that constructs a target URI from user-provided information, such as the query fields of a form using GET, potentially sensitive data might be provided that would not be appropriate for disclosure within a URI (see Section 17.9). In some cases, the data can be filtered or transformed such that it would not reveal such information. In others, particularly when there is no benefit from caching a response, using the POST method (Section 9.3.3) instead of GET can transmit such information in the request content rather than within the target URI.

I dalej:

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server. This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access log files at the completion of every response, regardless of the method, and that is considered safe even though the log storage might become full and cause the server to fail. Likewise, a safe request initiated by selecting an advertisement on the Web will often have the side effect of charging an advertising account. Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.

I dalej:

URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added to templates when a page is printed, and stored in a variety of unprotected bookmark lists. Many servers, proxies, and user agents log or display the target URI in places where it might be visible to third parties. It is therefore unwise to include information within a URI that is sensitive, personally identifiable, or a risk to disclose. When an application uses client-side mechanisms to construct a target URI out of user-provided information, such as the query fields of a form using GET, potentially sensitive data might be provided that would not be appropriate for disclosure within a URI. POST is often preferred in such cases because it usually doesn't construct a URI; instead, POST of a form transmits the potentially sensitive data in the request content. However, this hinders caching and uses an unsafe method for what would otherwise be a safe request.

I dalej:

The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. For example, POST is used for the following functions (among others):
Providing a block of data, such as the fields entered into an HTML form, to a data-handling process;
Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles;
Creating a new resource that has yet to be identified by the origin server; and
Appending data to a resource's existing representation(s).

I dalej:

Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [CACHING]) and a Content-Location header field that has the same value as the POST's target URI (Section 8.7). A cached POST response can be reused to satisfy a later GET or HEAD request. In contrast, a POST request cannot be satisfied by a cached POST response because POST is potentially unsafe; see Section 4 of [CACHING].

W konsekwencji:

Riddle napisał(a):

Pod względem tego jak "wrażliwe" są dane, to nie ma to żadnego znaczenia. Request HTTP to request, nie różni się praktycznie niczym, oprócz słowa GET/POST w nagłówku i tego czy ma body czy nie.

Nieprawda, specyfikacja jawnie głosi, że GET się nie nadaje do przesyłania wrażliwych danych, przynajmniej nie bez dodatkowego szyfrowania ich, usuwania ich, filtrowania ich itp.

Riddle napisał(a):

Brednie Nie prawda, bo po pierwsze GET'em też możesz wysłać dane, np w nagłówku lub w query params; i postem też możesz odebrać dane, np w response body. Więc obiema metodami da się zarówno wysyłać i odbierać dane, różnica jest tylko w formie.

Riddle napisał(a):

Nie mówię że powinno się wysyłać wrażliwe dane w query, w ulru, w headereach czy w body - to już zależy co chcesz osiągnąć, ale pod względem tego jaka to metoda to POST/GET są właściwie takie same.

Riddle napisał(a):

Co do tego że określiłem to co napisałeś słowem "brednie", chodziło o Twoją wypowiedź "POST'em się wysyła, GET'em się odbiera". Tak jak rozumiem czemu ktoś mógłby tak to określić, tak to jest tożsama sytuacja co określenie "Nożem się kroi, a widelcem się nabija". Rozumiem, czemu ktoś by tak powiedział, ale niestety prawdą jest że widelcem też można coś przekroić, a nożem też można coś nabić; podobnie jak mimo że "POST'em się wysyła, GET'em się odbiera" tak można wysłać dane GET'em i odebrać POST'em - to miałem na myśli mówiąć "brednie", być może lepiej byłoby użyć słowa "prawdziwe inaczej".

Nieprawda, bo specyfikacja jawnie glosi, do czego służy GET, a do czego służy POST. Oczywiście, technicznie rzecz ujmując MOŻNA specyfikacji nie słuchać i robić po swojemu, a potem się dziwić, czemu nic nie działa, bo serwery cache'ujące żądania, przeglądarki, cały świat jednak słucha specyfikacji, a nie mojego widzimisię.

Riddle napisał(a):

Jak sprecyzujesz dokładnie co znaczy "się robi", to zrozumiesz że to jest jakby preferencja, a nie faktyczna cecha HTTP.

Nieprawda, to jest określone w specyfikacji, a zresztą nawet gdyby to była tylko preferencja, to jeśli coś jest już de-facto standard, to należy uznawać to za standard.

Riddle napisał(a):

Innymi słowy - jeśli coś da się wykraść z GET'a, to tak samo łatwo to wykraść z POST'a. Więc pod względem bezpieczeństwa - nie ma różnicy.

Riddle napisał(a):

Poza tym, jeśli coś jest w stanie podglądnąć URL requestu, to jest w stanie podglądnąć też body. Więc użycie POST będzie tylko pozornie bardziej bezpieczne. Wylicz wszystkie miejsca gdzie używając GET'a możesz się narazić na wyciech danych - wszystkie te miejsca również są podatne na wyciek dla POST.

Riddle napisał(a):

Cały zamysł mojej odpowiedzi, dotyczył tego, że umieszczając dane w POST, wcale nie sprawimy że te dane będą jakkolwiek "bardziej bezpieczne". Obie te rzeczy są zwykłymi requestami HTTP, obie są przekazywane przez przeglądarkę, sieć, server i analizowane przez aplikacje backendową. Owszem, są pewne konwencje i domyślne ustawienia które w tych czy innych przypadkach traktują te żądania inaczej; ale ostatecznie pod względem komunikacji między serverem a klientem to to jest to samo. Jeśli na drodze między serverem a klientem jest coś co może podglądnąć ten request, to tak samo POST jak i GET jest na to podatny. Nie dawajmy pytającemu złudnego wrażenia że może "ochronić swoje dane" zmieniając metodę HTTP.

Nieprawda. W skrajnie uproszczonym, przeteoretyzowanym modelu istotnie można twierdzić, że GET przesyłający dane w URLu vs. POST przesyłający dane w URLu vs. POST przesyłający dane w ciele żądania to jedno i to samo: można podsłuchać, jesli nie jest szyfrowane, nie można podsłuchać, jeśli jest szyfrowane. Jednak konwencje i specyfikacje są jakie są, a to oznacza, że wszelkie serwery pośredniczące, serwery logów, przeglądarki i ogólnie większość świata postępuje z metodami GET w taki sposób, a z metodami POST w inny sposób. W konsekwencji żądania GET będą cache'owane, logowane i zapisywane na prawo i lewo , podczas gdy żądania POST już mniej, a ciała żądań POST jeszcze mniej. Ergo twierdzić, że "nie ma różnicy" oraz "tak samo łatwo wykraść" to ciężka przesada i nieprawda, ponieważ łatwość wykradnięcia danych zależy od tego, jak różne serwery, narzędzia i oprogramowania się z nimi obchodzą! Załóżmy, że pr0 h4x0r przejął jakiś serwer cache. Czy z tego tytułu otrzymał dostęp do (a) historycznych żądań GET, czy (b) historycznych żądań POST? chyba jest jasne, która możliwość jest bardziej prawdopodobna. I Riddle jest tego świadomy, skoro sam pisze, że "są pewne konwencje i domyślne ustawienia które w tych czy innych przypadkach traktują te żądania inaczej".

@YetAnohterone: Chyba trochę szalejesz. Ruch pomiędzy enpointem a klientem jest szyfrowany e2e. W żądaniu GET zawierającym jakieś query paramteres, te parametry nie będą mogły zostać łatwo przechwycone przez cokolwiek po środku, bo w żądaniu jawny jest protokół (https) i domena do której leci żądanie.
Głównym powodem, dla którego nie powinno się wrzucać istotnych rzeczy do URL jest fakt, że ten url można skopiować i wysłać. Dlatego nie należy tam wrzucać danych autoryzacyjnych, oraz danych, które użytkownik może uznawać za prywatne.
Oczywiście po stronie serwera, zwykle request GET jest logowany w całości, a POST nie bardzo, ale zakładając, że to twój serwer, powinieneś wiedzieć co logujesz.
Co do części o cache, transparent proxy itd. Owszem odpowiedź w formie zaszyfrowanej może zostać zarejestrowana, ale jak wyżej - szyfrowanie jest e2e. Zresztą takie ryzyko dotyczy przesyłania w obie strony.

@piotrpo:

Cyt. za dokumentacją WooCommerce:

Authentication over HTTPS

You may use HTTP Basic Auth by providing the REST API Consumer Key as the username and the REST API Consumer Secret as the password.

Occasionally some servers may not parse the Authorization header correctly (if you see a "Consumer key is missing" error when authenticating over SSL, you have a server issue). In this case, you may provide the consumer key/secret as query string parameters instead.

Źródło: https://woocommerce.github.io/woocommerce-rest-api-docs/#authentication-over-https

Oczywiście po stronie serwera, zwykle request GET jest logowany w całości, a POST nie bardzo, ale zakładając, że to twój serwer, powinieneś wiedzieć co logujesz.

Sklepik zakłada sobie stronę internetową, więc oczywiście by default ustawiono im logowanie wszystkich URLi wszystkich żądań. Ale teraz sklepik korzysta w jakiejśtam wtyczki np. do synchronizacji towarów między WC a jakiś tam systemem uzanym za źródło prawdy. Tak się składa, że wtyczka ta, by zapewnić sobie niezawodność (uniknąć problemu opisanego w dokumentacji) wysyła dane autoryzacyjne w query string.

Od teraz dane autoryzacyjne walają się plaintextem po logach.

Stamtąd mogą wyciec gdziekolwiek w dowolny sposób.

Co do serwerów cache - masz rację, chyba, że znowu to samo: to jest wewnętrzny serwer cache.

@YetAnohterone: No ok, ale:

1. Temat jest o przesyłaniu niewrażliwych danych.
2. Basic authentication pomiędzy urządzeniami - jak by nie patrzeć trochę śmierdzi.
3. Jeżeli serwer, do którego przekazujesz wrażliwe dane, dumpuje je do logów, bo tak mu się podoba, a później te logi przechowuje w sposób niedbały, to nie specjalnie jesteś w stanie cokolwiek poradzić, bo nawet nie wiesz o tym problemie.

piotrpo napisał(a):

@YetAnohterone: No ok, ale:

1. Temat jest o przesyłaniu niewrażliwych danych.

Zgadza się. Ale to nie ja zacząłem ten offtop. Ja go tylko kontynuuję :)

3. Basic authentication pomiędzy urządzeniami - jak by nie patrzeć trochę śmierdzi.

Hej, nie ja pisałem WooCommerce :)

5. Jeżeli serwer, do którego przekazujesz wrażliwe dane, dumpuje je do logów, bo tak mu się podoba, a później te logi przechowuje w sposób niedbały, to nie specjalnie jesteś w stanie cokolwiek poradzić, bo nawet nie wiesz o tym problemie.

Tak, ale o to chodzi, że p-stwo, że gdzieś tam będą logowane sobie URLe GETów lub POSTów jest wyraźnie większe, niż p-stwo, że gdzieś tam będą logowane sobie ciała POSTów. Tak samo p-stwo, że gdzieś tam będą sobie cache'owane GETy jest wyraźnie większe, niż p-stwo, że gdzieś tam będą sobie cache'owane POSTy, a nie wszystkie cache'y są zewnętrzne.