C'è un vantaggio di sicurezza nel richiedere una richiesta di conformità a / api / 1234 invece di / api / me? Entrambi avrebbero ovviamente token di accesso.
La mia ipotesi è che api / 1234 sia più sicuro perché se qualcuno si impossessa di un token di accesso, non può semplicemente vedere chi è. Devono sapere a quale ID utente appartiene il token.
Risposta breve: non importa
In alcuni casi l'utilizzo di / api / 1234 potrebbe essere uno svantaggio. Se l'applicazione non dispone di controlli di autorizzazione appropriati, un utente può provare / api / 1235 e accedere all'account di un altro utente. Questo tipo di vulnerabilità è sorprendentemente comune nella pratica. / api / me è buono perché obbliga lo sviluppatore a recuperare l'ID dalla sessione.
/ api / 1234 può essere un vantaggio se l'ID utente è un segreto. Questo dipende dall'applicazione - in genere con applicazioni interattive, gli utenti possono vedere gli ID di altri utenti. Se l'ID è veramente segreto, questo protegge contro CSRF. Tuttavia, l'applicazione dovrebbe già avere una protezione CSRF, solitamente attraverso un token in un campo nascosto.
In generale, se qualcuno si impossessa di un token di accesso, tutte le scommesse sono disattivate. Focalizza la tua attenzione sulla sicurezza per impedire a chiunque di impossessarsi di un token.
Sì, è vero che avrebbero bisogno di un'informazione aggiuntiva se si richiede anche l'id dell'utente, quindi suppongo che sia più sicuro.
Detto questo, ho il sospetto che se un token di accesso è stato rubato, è probabile che anche l'ID utente sia stato rubato. Anche se non lo fosse, se usi ID sequenziali (come fa il tuo esempio) e non GUID o qualcosa del genere, potrebbero semplicemente attivare una richiesta per /api/1 fino a /api/1000000 e vedere se ottengono risultati positivi.
Leggi altre domande sui tag authentication access-control web-application