Prima di tutto: Se il token è concatenato in una query SQL (senza escape sufficiente), quindi si , può essere usato per l'iniezione SQL. Non creare query con la concatenazione!
I token, da soli, non hanno permessi; sono solo identificatori. La logica dell'app determina quali permessi fornire al portatore del token, ma spetta all'applicazione applicarla e un'iniezione SQL (riuscita) ignora tali controlli. I database hanno anche permessi (almeno quelli migliori) e l'app avrà determinate autorizzazioni sul database che determinano cosa può fare una query che l'app invia al DB (e tutto ciò che è un'iniezione SQL, dal punto di vista di il DB, è una query su cui è stata inviata l'app). Un'app molto attenta alla sicurezza utilizzerà il principio del privilegio minimo (che dice che non si dovrebbero mai concedere più autorizzazioni di quante ne siano necessarie per eseguire il proprio compito), in modo tale che (ad esempio) una query DB che dovrebbe essere di sola lettura essere fatto usando una connessione con autorizzazione di sola lettura sul DB, e in tal caso una subquery DELETE
incorporata fallirebbe davvero. Tuttavia, in pratica pochissimi sviluppatori lo fanno e l'app di solito fa tutte le query usando una connessione con permessi completi sul DB.
Le autorizzazioni dell'entità identificata dal token (presumibilmente un utente di un'app Web o simile) non hanno alcun rapporto con le autorizzazioni che l'app ha quando parla al suo database. Infatti, poiché un'iniezione SQL richiede la modifica del token, in realtà non è più l'identificatore corretto per quell'utente, quindi sicuramente non sarà soggetto a controlli di accesso specifici per l'utente.