La sicurezza riguarda l'HTTP GET nello sviluppo Web

• Oltre le connessioni TLS (https), entrambi i dati POST e GET sono crittografati, quindi non c'è alcuna differenza in proposito.
• Per evitare problemi di SQL injection (o altri), devi convalidare e disinfettare tutto l'input dell'utente in entrata, indipendentemente dal fatto che sia stato utilizzato POST o GET.
• Inerentemente, l'utilizzo delle richieste POST non è più sicuro , ma è buona norma utilizzare le richieste POST quando si inviano dati che modificano (ad esempio) qualcosa nel database.

• Se si utilizza GET, esiste un rischio maggiore che gli strumenti di registrazione del server registrino anche le informazioni riservate per impostazione predefinita (il registro delle richieste HTTP conterrà tutti i dati). Puoi minimizzare questo rischio inviando i dati con POST.

• Inoltre, in alcuni scenari (a seconda dell'utilizzo e delle esigenze specifici), le informazioni sensibili nell'URL come parametri di query (ad esempio /data/something?secret_key=123321 ) verranno anche memorizzate nella cronologia del browser e ciò potrebbe essere un rischio se i computer condivisi sono comuni per i tuoi utenti.

Sembra che tu stia combinando diversi problemi in termini di sicurezza. Ci sono alcuni problemi con l'utilizzo dei parametri GET, sebbene questi non siano specificamente correlati all'iniezione SQL e l'iniezione SQL non può essere prevenuta usando solo le richieste POST.

La maggior parte dei problemi con le richieste GET deriva dall'accesso indiretto ai dati: ad esempio, i parametri GET possono essere visualizzati nella cronologia del browser e memorizzati nei file di registro lato server senza alcuna elaborazione aggiuntiva. Le richieste POST, d'altra parte, vengono solitamente visualizzate nella cronologia del browser senza valori di parametro e i registri del server di solito non includono il corpo delle richieste.

SQLi, d'altra parte, risulta dall'utilizzo di dati non affidabili nel contesto di una query SQL. Non importa da dove provengano i dati: richiesta GET, richiesta POST, altro sistema di backend, cookie, il database stesso.

Generalmente è buona pratica applicare rigorosamente metodi di richiesta specifici, ma è meglio evitare altri tipi di difetti (le versioni precedenti di PHP unirebbero le variabili GET e POST, ad esempio, causando problemi in cui i valori previsti potrebbero essere sovrascritti da fornire un parametro inserito dall'utente dell'altro tipo). Un paradigma per questo sta seguendo i metodi REST ( link ) in cui ogni metodo HTTP si associa a un tipo di azione, quindi solo richieste GET recupera i dati, le richieste POST creano i dati, PUT richiede i dati di aggiornamento e le richieste DELETE eliminano i dati, ma questo non ha sempre senso per tutte le applicazioni (ad esempio dove fare richieste PUT / DELETE non è possibile per qualche motivo).

Per aggiungere alle risposte eccessive senza troppe sovrapposizioni, la preoccupazione per gli URL non è infondata e ci sono specifiche raccomandazioni per questo: "Nelle richieste GET i dati sensibili devono essere trasferiti in un'intestazione HTTP"

Come notato nel mio commento su un'altra risposta, qualsiasi cosa fatta con GET deve essere idempotente e sicuro .

GET e POST (lunghi con PUT, DELETE e PATCH) hanno ruoli funzionali molto specifici , ridefinendo la semantica di questi non è qualcosa da prendere senza un'attenta considerazione.

Anche quando si utilizza il POST, se si seguono le convenzioni REST, vi sono informazioni transazionali significative all'interno dell'URL.

Se utilizzi qualsiasi tipo di contenuto transazionale o contenuto che richiede l'autenticazione, devi utilizzare HTTPS. Questo (principalmente) riguarda la riservatezza dei dati in transito. I tuoi problemi rimanenti sono agli endpoint. Presumibilmente il lato server non è un problema. Sul client, i dati rimarranno nella cronologia del dispositivo ma solo per gli URL a cui l'utente ha navigato - XMLHttpRequests non popola la cronologia a meno che tu inserisce esplicitamente i dati .

I browser sono relativamente bravi a partizionare i dati appartenenti a siti separati - ma ci sono vari canali che possono far trapelare informazioni ad un determinato utente malintenzionato ma questi sono tutti (AFAIK) nel dominio dei dati statici - nomi host, certificati, stato HSTS, cache dei contenuti ... la cronologia del browser non è uno di questi.

Quindi, a parte il modello di minaccia di qualcuno che si impadronisce del dispositivo di un utente ed estrae i dati dal filesystem, non c'è differenza tra un GET e un POST dal punto di vista della sicurezza.

Serverside, la sua pratica comune per registrare l'intero URL, quindi ti consigliamo di acquistare protezioni simili ai tuoi dati di registro come fai con i dati transazionali.