Com'è fatta davvero una URL: guida semplice a dominio, path, query string e sicurezza

Ogni giorno clicchiamo link senza leggerli davvero. Li riceviamo via email, li apriamo da una chat, li copiamo da un sito, li incolliamo in documenti di lavoro e li condividiamo sui social. Spesso ci basta che qualcosa “sembri un link” per considerarlo affidabile.

Eppure una URL non è solo un indirizzo web da cliccare. È una piccola istruzione tecnica. Dice al browser come comunicare, quale server contattare, quale risorsa chiedere, quali parametri inviare e, in alcuni casi, in quale punto della pagina posizionarsi.

Capire com’è fatta una URL è una competenza semplice, ma molto utile. Serve a chi usa il web tutti i giorni, perché aiuta a riconoscere link sospetti e tentativi di phishing. Serve anche a chi sviluppa software, perché le URL sono parte dell’interfaccia di un’applicazione web e influenzano leggibilità, debug, log, documentazione e manutenzione.

In questa guida vediamo le parti principali di una URL: protocollo, dominio reale, sottodominio, porta, path, query string e fragment. Lo faremo con esempi pratici, senza trasformare il discorso in una lezione astratta.

Cos’è una URL

URL significa Uniform Resource Locator. In italiano possiamo pensarla come un localizzatore di risorse. Una URL indica dove si trova una risorsa e come raggiungerla.

La risorsa può essere una pagina HTML, un’immagine, un file PDF, un endpoint API, un documento, una pagina di login, un pannello di amministrazione o una sezione specifica di un sito.

Quando scriviamo o clicchiamo una URL, non stiamo semplicemente dicendo al browser “apri questo link”. Stiamo dando un’istruzione più precisa:

• usa questo protocollo;
• contatta questo host;
• usa questa porta, se indicata;
• chiedi questa risorsa;
• passa questi parametri;
• se serve, vai a questa sezione della pagina.

Questa è la ragione per cui leggere una URL con attenzione può raccontare molto su quello che sta per succedere.

Esempio completo di URL

Partiamo da un esempio completo:

https://www.example.com:443/prodotti/scarpe?colore=nero&taglia=42#recensioni

A prima vista sembra una stringa unica. In realtà contiene pezzi diversi:

https://                  protocollo
www                       sottodominio
example.com               dominio
:443                      porta
/prodotti/scarpe          path
?colore=nero&taglia=42    query string
#recensioni               fragment

Ogni parte ha un ruolo. Non serve memorizzare tutto come una formula, ma è importante abituarsi a riconoscere la struttura. Una URL assomiglia a una frase tecnica: ogni pezzo aggiunge un’informazione.

Protocollo: HTTP, HTTPS e lucchetto

La prima parte della URL è il protocollo:

https://

Il protocollo dice al browser come comunicare con il server. Nel web i casi più comuni sono http:// e https://.

HTTPS significa che la comunicazione HTTP viaggia dentro un canale cifrato tramite TLS. Questo è fondamentale quando inseriamo password, dati personali, informazioni bancarie, documenti o qualunque contenuto sensibile.

Se una pagina usa http://, senza la esse finale, la comunicazione non offre lo stesso livello di protezione durante il transito. Per una vecchia pagina statica può essere un problema limitato. Per un login, un pagamento o l’invio di dati personali, invece, non è accettabile.

Attenzione però a un punto importante: HTTPS non significa automaticamente sito affidabile.

HTTPS dice che la connessione verso quel sito è cifrata. Non dice che il sito sia legittimo, onesto o sicuro dal punto di vista applicativo. Anche un sito di phishing può usare HTTPS. Anche una pagina falsa può mostrare il lucchetto nel browser.

Il lucchetto non significa “questo sito è buono”. Significa solo “la connessione verso questo sito è cifrata”.

Nome host, dominio reale e sottodominio

Dopo il protocollo troviamo il nome host:

www.example.com

In questo caso www è un sottodominio, mentre example.com è il dominio principale.

Questa distinzione è una delle cose più importanti da capire quando si parla di URL e sicurezza web. Molti link sospetti non funzionano perché sono tecnicamente complessi, ma perché vengono letti troppo in fretta.

Confrontiamo questi due indirizzi:

https://login.example.com
https://example-login.com

Sembrano simili, ma non sono la stessa cosa.

Nel primo caso siamo dentro example.com, in un sottodominio chiamato login. Nel secondo caso siamo su un dominio completamente diverso: example-login.com.

Questo dettaglio è centrale nel phishing. Un attaccante può usare parole familiari dentro il link per creare fiducia: login, secure, account, documenti, banca, cloud, spedizione. Ma la domanda corretta non è “vedo una parola che conosco?”. La domanda corretta è:

qual è il dominio reale?

Un esempio ancora più chiaro:

https://paypal.com.secure-login.example.net

A una lettura veloce potremmo notare paypal.com. Il dominio reale, però, è example.net. Tutto quello che viene prima è una sequenza di sottodomini.

Per il browser questa destinazione non è paypal.com.

Come riconoscere il dominio reale in una URL

Per leggere il dominio reale bisogna guardare la parte finale del nome host, subito prima del path.

Prendiamo questa URL:

https://servizio.com.login.example.net/accesso

Il path è /accesso. Il nome host è:

servizio.com.login.example.net

Il dominio reale è example.net. Le parti precedenti, cioè servizio, com e login, sono sottodomini.

Questa abitudine è utile quando riceviamo link via email, SMS, chat o messaggi privati. Prima di inserire credenziali o dati personali, conviene sempre fermarsi un momento e leggere il dominio reale.

Porta: cosa significa :443, :80, :3000 o :8080

Dopo il dominio può comparire una porta:

:443

La porta indica a quale servizio ci stiamo collegando. Per il web le porte più comuni sono:

• 80 per HTTP;
• 443 per HTTPS.

Di solito il browser le sottintende. Se scriviamo:

https://example.com

normalmente viene usata la porta 443. Se scriviamo:

http://example.com

normalmente viene usata la porta 80.

In ambienti tecnici, però, possiamo incontrare porte diverse:

http://localhost:3000
https://example.com:8443
http://192.168.1.50:8080/admin

Chi sviluppa software vede spesso localhost:3000, localhost:5173, localhost:8000 o indirizzi simili. Sono tipici di applicazioni in sviluppo sul proprio computer.

Dal punto di vista della sicurezza, una porta esposta è una superficie da capire. Non è automaticamente un problema, ma se un servizio non deve essere raggiungibile da Internet, non dovrebbe essere pubblico.

Un pannello amministrativo esposto su una porta non standard non diventa sicuro solo perché “non è sulla porta 443”. La sicurezza non deve dipendere dalla speranza che nessuno trovi l’indirizzo.

Path: la risorsa richiesta

Il path indica la risorsa richiesta:

/prodotti/scarpe

Può rappresentare una pagina, un file, una rotta applicativa o un endpoint API.

Esempi:

https://example.com/prodotti/scarpe
https://example.com/api/users/42
https://example.com/admin
https://example.com/upload

Il primo indirizzo può indicare una pagina di catalogo. Il secondo sembra una richiesta verso un’API, probabilmente relativa all’utente con ID 42. Il terzo punta a un’area amministrativa. Il quarto richiama una funzionalità di upload.

Il path può raccontare molto su come è organizzata un’applicazione web. Percorsi come /admin, /backup, /test, /old, /debug o /upload non sono automaticamente vulnerabili, ma meritano attenzione.

Un percorso sensibile non dovrebbe essere pubblico solo perché “tanto nessuno lo conosce”. Questo approccio si chiama spesso security through obscurity: può ridurre un po’ la visibilità, ma non sostituisce autenticazione, autorizzazioni e controlli corretti.

Query string: parametri nella URL

La query string è la parte della URL che inizia con ?:

?colore=nero&taglia=42

Serve a inviare parametri al server. Di solito questi parametri hanno una forma chiave-valore. Nel nostro esempio:

colore = nero
taglia = 42

Altri esempi comuni:

https://shop.example.com/search?q=notebook
https://blog.example.com/articoli?page=2
https://example.com/report?anno=2026&formato=pdf

Nel primo caso il parametro q contiene la ricerca. Nel secondo il parametro page indica la pagina degli articoli da visualizzare. Nel terzo la query string specifica anno e formato del report.

Le query string sono molto comode, ma vanno progettate con attenzione. Non dovrebbero contenere password, token permanenti, dati personali non necessari o informazioni che non vogliamo vedere comparire in log e strumenti di monitoraggio.

Il motivo è semplice: una URL non è un luogo privato.

Una URL può finire nella cronologia del browser, nei log del server, in uno screenshot, in un proxy aziendale, in un sistema di analytics, in uno strumento di monitoraggio o in una chat.

Anche quando la connessione è HTTPS, la URL può essere registrata o condivisa in contesti dove non ce ne accorgiamo.

URL con token: perché bisogna fare attenzione

Alcuni link contengono token o codici temporanei:

https://example.com/reset-password?token=abc123
https://example.com/invito?code=xyz789
https://example.com/documento?access_token=...

Questi link possono essere legittimi. Pensiamo a un reset password, a un invito a un documento o a un accesso temporaneo.

Il problema è che, in quei casi, la URL funziona quasi come una chiave. Chi possiede il link potrebbe riuscire ad accedere a una risorsa o completare un’azione.

Per questo non bisogna inoltrare URL con token senza capire cosa contengono. Se un link dà accesso a qualcosa, condividerlo può significare trasferire quell’accesso a un’altra persona.

Fragment: la parte dopo il cancelletto

La parte finale dopo # si chiama fragment:

#recensioni

Spesso serve a portare il browser direttamente a una sezione della pagina:

https://example.com/guida#installazione

In questo caso il browser apre la pagina e prova a posizionarsi nella sezione installazione.

In molte applicazioni moderne il fragment può anche essere usato per gestire parti dell’interfaccia lato client. L’idea di base, però, resta semplice: è un riferimento interno alla pagina o all’applicazione.

URL e sicurezza: tre esempi pratici

Leggere una URL aiuta a notare anomalie semplici ma importanti.

Esempio 1: URL coerente

https://intranet.azienda.local/documenti/report.pdf

Questa URL sembra interna. Il sottodominio è intranet, il path punta a un documento, non ci sono parametri strani. Non basta per dire che sia sicura, perché il contesto conta sempre, ma la struttura è coerente.

Esempio 2: URL sospetta

https://azienda.documenti-login.com/accesso

Qui vediamo parole familiari: azienda, documenti, login. Però il dominio reale è documenti-login.com, non il dominio aziendale.

Questo è un campanello d’allarme. Il link sta usando parole riconoscibili per sembrare più credibile.

Esempio 3: URL tecnica

http://192.168.1.50:8080/admin

Qui non c’è un dominio, ma un indirizzo IP privato. Il protocollo è HTTP. La porta è 8080. Il path è /admin.

Potrebbe essere un pannello locale, un router, una stampante, un servizio interno o un’applicazione in rete locale. In un contesto corretto può avere senso. Fuori contesto, va osservata con prudenza.

URL, phishing e link sospetti

Molti tentativi di phishing non richiedono tecniche sofisticate. Spesso sfruttano fretta, abitudine e somiglianza visiva.

Un link può contenere parole come login, secure, documenti, pagamento, account, verifica o il nome di un servizio conosciuto. Ma quello che conta è il dominio reale.

Prima di cliccare un link ricevuto via email o messaggio, soprattutto se richiede login o dati personali, conviene controllare:

• il protocollo è coerente?
• il dominio reale è quello atteso?
• ci sono parole familiari usate come sottodomini per confondere?
• la query string contiene token, codici o redirect strani?
• il contesto del messaggio ha senso?

Non dobbiamo diventare paranoici. Dobbiamo diventare più attenti.

URL e sviluppo web: perché progettare indirizzi leggibili

Per chi sviluppa, le URL non sono solo dettagli tecnici. Sono parte dell’interfaccia dell’applicazione.

Una URL chiara aiuta:

• gli utenti a capire dove si trovano;
• gli sviluppatori durante debug e manutenzione;
• i log a essere più leggibili;
• i test automatici a essere più chiari;
• la documentazione a essere più semplice;
• il posizionamento SEO, quando la URL descrive bene il contenuto.

Confrontiamo:

/api/v1/users/42/orders

con:

/do.php?action=get_data&type=7&id=42

La seconda può funzionare. La prima, però, comunica meglio la struttura: utenti, ordini, relazione tra risorse.

Una URL pulita non garantisce automaticamente sicurezza. Un endpoint elegante può essere vulnerabile, e una URL brutta può essere protetta bene. Però un sistema leggibile è più facile da capire, testare e controllare.

Checklist: come leggere una URL prima di cliccare

Quando ricevi un link, soprattutto se arriva da email, SMS o chat, puoi usare questa piccola checklist:

1. Guarda il protocollo: https:// è presente?
2. Cerca il dominio reale, non solo le parole familiari.
3. Controlla se il dominio è simile ma non identico a quello atteso.
4. Osserva il path: porta a una sezione coerente?
5. Guarda la query string: contiene token, codici, redirect o dati personali?
6. Valuta il contesto: ti aspettavi davvero quel link?
7. Prima di inserire credenziali, fermati e rileggi.

Questa abitudine non elimina tutti i rischi, ma riduce molti errori comuni.

Tre regole pratiche

Se vuoi ricordare solo tre cose, tieni queste:

La prima: guarda il dominio reale, non solo le parole presenti nel link.

La seconda: non inserire dati sensibili se protocollo, dominio o contesto non tornano.

La terza: non condividere URL che contengono token, codici o dati personali.

Domande frequenti sulle URL

Che differenza c’è tra URL e dominio?

Il dominio è una parte della URL. Per esempio, in https://www.example.com/prodotti, il dominio principale è example.com. La URL completa include anche protocollo, eventuale sottodominio, path, query string e fragment.

HTTPS rende una URL sicura?

HTTPS rende cifrata la connessione tra browser e server, ma non garantisce che il sito sia affidabile. Un sito falso può usare HTTPS. Per questo bisogna controllare anche dominio reale e contesto.

Cos’è la query string in una URL?

La query string è la parte dopo ?. Serve a passare parametri al server, per esempio una ricerca, un filtro o un numero di pagina. Non dovrebbe contenere password, token permanenti o dati personali non necessari.

Come capisco se una URL è sospetta?

Una URL può essere sospetta se il dominio reale non è quello atteso, se usa parole familiari in modo ingannevole, se contiene redirect strani, token non chiari o se arriva in un contesto anomalo, per esempio una richiesta urgente di login.

Perché le URL sono importanti per chi sviluppa?

Perché sono parte dell’interfaccia dell’applicazione. URL leggibili rendono più semplice capire, testare, documentare e mantenere un sistema. Inoltre, nelle pagine pubbliche, URL descrittive possono aiutare anche la SEO.

Conclusione

Una URL non è solo un link. È una frase tecnica che il browser interpreta per raggiungere una risorsa.

Capire com’è fatta una URL aiuta a usare meglio il web, riconoscere molti link sospetti e progettare applicazioni più ordinate. È una competenza di base, ma ha effetti concreti: riduce confusione, migliora la sicurezza e rende più chiaro il modo in cui funzionano siti, API e applicazioni web.

La URL è il primo strato. Subito sotto c’è un’altra domanda fondamentale: quando scriviamo un dominio come example.com, come fa il computer a sapere quale server contattare?

La risposta si chiama DNS.