HTTP QUERY (RFC 10008): dopo oltre 15 anni arriva il metodo giusto per le query. Più sicurezza, meno compromessi

Una lacuna che gli sviluppatori conoscono da oltre 15 anni

Chi sviluppa applicazioni web si è trovato almeno una volta davanti allo stesso problema: effettuare una ricerca complessa senza modificare i dati del server.

Il metodo GET è sempre stato la scelta naturale per recuperare informazioni, ma costringe ad inserire tutti i parametri nell'URL. Quando le ricerche diventano articolate, con filtri, JSON, GraphQL o centinaia di parametri, la query string diventa rapidamente ingestibile.

Per questo motivo moltissimi sviluppatori hanno iniziato ad utilizzare POST anche per semplici operazioni di lettura. Una soluzione pratica, ma non corretta dal punto di vista del protocollo HTTP. La stessa RFC 10008 nasce proprio per eliminare questo compromesso.

Perché usare POST per leggere dati non era la soluzione ideale?

POST è stato progettato per creare, modificare o elaborare dati sul server. Quando viene utilizzato solamente per effettuare una ricerca si perde gran parte del significato semantico del protocollo HTTP.

• cache meno efficienti;
• retry automatici più complessi;
• API meno leggibili;
• comportamenti differenti tra proxy e CDN;
• documentazione tecnica meno chiara.

Non si trattava tanto di una vulnerabilità, quanto di una limitazione storica dell'architettura HTTP.

Nasce HTTP QUERY

La RFC 10008 introduce ufficialmente il nuovo metodo QUERY.

QUERY permette di inviare la richiesta nel body, esattamente come POST, ma mantiene le caratteristiche fondamentali di GET:

• operazione sicura (safe);
• idempotente;
• cacheabile;
• ripetibile automaticamente senza effetti collaterali.

In altre parole è il metodo che molti framework simulavano già da anni attraverso endpoint come POST /search. Ora esiste finalmente uno standard ufficiale.

Dal punto di vista della sicurezza cosa cambia?

È importante chiarire un aspetto.

Tuttavia introduce alcuni vantaggi concreti:

• meno dati esposti negli URL;
• minore probabilità che informazioni sensibili finiscano nei log;
• query molto grandi senza limiti della query string;
• migliore gestione delle cache;
• maggiore chiarezza semantica delle API.

Naturalmente HTTPS rimane indispensabile e continua ad essere la prima misura di protezione del traffico.

Possiamo già utilizzarlo?

Non ancora ovunque.

La RFC è stata pubblicata come Proposed Standard, ma browser, framework, reverse proxy, CDN, firewall applicativi, API Gateway e librerie HTTP dovranno implementare il nuovo metodo prima che diventi di uso comune.

Per diverso tempo continueremo probabilmente a vedere endpoint come POST /search, semplicemente per garantire la compatibilità con browser e infrastrutture esistenti.

Cosa significa per aziende e professionisti?

Ogni evoluzione del protocollo HTTP rappresenta un'opportunità per migliorare sicurezza, prestazioni e qualità del software.

Se il vostro sito gestisce dati personali, pagamenti online, documenti riservati oppure applicazioni aziendali, è importante verificare periodicamente che l'infrastruttura rispetti le migliori pratiche di sicurezza, indipendentemente dal metodo HTTP utilizzato.

Conclusioni

HTTP QUERY rappresenta una delle evoluzioni più importanti del protocollo HTTP degli ultimi anni. Non sostituisce le buone pratiche di sviluppo né elimina le vulnerabilità applicative, ma offre finalmente uno standard corretto per le richieste di sola lettura con payload complessi.

Per gli sviluppatori significa API più pulite. Per le aziende significa infrastrutture più moderne. Per chi si occupa di cybersecurity è un ulteriore passo verso applicazioni più robuste, più coerenti e più semplici da proteggere.