Questo scenario impone molteplici problemi possibili. Indipendentemente dal fatto che sia soggetto a SQL Injection o hacking, non è possibile fornire una risposta in quanto è completamente dipendente dall'ambiente e dal codice.
L'intercettazione potrebbe verificarsi sul lato server durante la generazione dei collegamenti, attraverso il canale di posta o sul proprio computer.
Quando limiti i link che invii e prevedi di fare clic su di essi in ogni caso, anche se un hacker otterrebbe il link e lo userà prima di usarlo (prima che l'UUID sia scaduto), tutto quello che l'hacker può fare è eseguire la query che hai memorizzato in un database. Quindi potrebbe non esserci alcun vettore di attacco qui (a parte l'UUID che ha indovinato come @wj. Ha sottolineato)
Se i collegamenti ti portano in qualche area amministrativa, sei fregato perché non fornisci alcuna autenticazione e cerchi di ottenere sicurezza per oscurità (mantenendo segreti i link).
Un modo per ridurre il rischio (in un modo probabile probabile) è quello di proteggere il canale di trasmissione crittografando la posta con una crittografia asimmetrica, come PGP ecc., questo è descritto da @wj. Evelo e perdi ancora perché non hai protetto la risorsa (il server) ma solo il messaggio che porta al server.
Quello che considero un modo migliore è mettere l'autenticazione intorno al server in termini di credenziali di accesso o qualche altro tipo di autenticazione.
La risorsa deve essere protetta? Perché non è già protetto?
Quale framework dovresti usare dipende dal tuo ambiente, è PHP? Perl? ASP?
Suggerirei di utilizzare i framework MVC esistenti per determinati linguaggi che includono il concetto di autenticazione (Symfony, Zend, ASP MVC, ecc.).
Tuttavia, tieni presente che tutti questi framework non sono banali e richiedono una certa comprensione, dal momento che il semplice utilizzo di un framework può esporre più informazioni sul tuo server e quindi aumentare i vettori di attacco.
Naturalmente potrebbero esserci strumenti totalmente semplici e integrati adatti alle tue necessità, come usare il meccanismo htaccess di apache per fornire una protezione semplice ma efficace delle risorse.
Questo potrebbe proteggere il collegamento che viene chiamato senza credenziali appropriate, ma non necessariamente protegge il tuo server in quanto potresti avere una password di root debole, una password di amministrazione del database debole, ecc.
I modi per essere compromessi sono così enormi. Anche se proteggi bene la tua risorsa, avere un CMS, un web-mailer o qualsiasi altro sistema installato sulla stessa macchina può fornire un vettore di attacco anche se hai ben protetto il tuo link (potresti finire con una porta sicura ma lascia aperte tutte le finestre, parlando in analogie:))