Sono troppo ingegnoso se considero l'errore intenzionale dell'utente?

Over-engineering? Affatto. Le misure anti-XSRF sono una parte necessaria di qualsiasi applicazione o servizio Web sicuro. Potrebbe essere o meno "altamente improbabile" che qualcuno scelga di attaccarti, ma ciò non rende il tuo software meno insicuro.

I sistemi sono stati comunemente attaccati usando XSRF, e anche se i risultati sono meno immediati, ovviamente negativi di SQL-injection o XSS, sono abbastanza brutti da compromettere tutte le funzionalità intercambiabili dall'utente.

Ciò significa che non puoi avere un'interfaccia "pura" RESTful in cui i parametri solo sono le proprietà della chiamata stessa. Devi includere qualcosa nella richiesta che un utente malintenzionato non può indovinare. Quella potrebbe essere la coppia nome utente-password, ma questo è lontano dall'unica scelta possibile. Potresti avere il nome utente insieme al token generato da un hash salato della password. Potresti avere token emessi dal servizio stesso al momento dell'autenticazione (che potrebbero essere ricordati nella sessione o verificati crittograficamente).

should I get rid of the GET

No, le richieste GET vengono utilizzate per richieste di lettura che non hanno alcuna operazione di scrittura attiva (sono "idempotenti"). Sono solo le operazioni di scrittura che richiedono la protezione XSRF.

Non fidarti mai di nulla. Ogni richiesta è un attacco. Ogni utente è un hacker. Se sviluppi con questa mentalità, la tua applicazione sarà molto più sicura, stabile e meno probabilità di essere dirottata da un utente malintenzionato. Tutto ciò che serve è una persona intelligente per trovare un modo per proteggere la tua sicurezza nei tuoi guai gravi con i tuoi dati (una delle tue risorse più preziose ).

Se hai identificato un buco di sicurezza nella tua applicazione, fai tutto ciò che pensi di dover fare per colmare il divario. La tua API, in particolare, dovrebbe essere il software di software più inaffidabile esistente. Richiedo le credenziali e vado con le richieste Post.

Se il codice è stabilito e mantenuto, i casi limite dovrebbero essere esaminati e trattati caso per caso.

FISSAGGIO DOVUTO ALCUNI ERRORI DALLA PARTE MIA:

GET dovrebbe ancora essere usato come parte di un corretto servizio RESTful, l'autenticazione deve essere ancora lì in ogni caso. Quello che stavo cercando di ipotizzare era che per motivi di sicurezza GET è molto simile al POST ma post fa il suo lavoro senza mettere le informazioni in una barra degli indirizzi, che tende ad essere la grande differenza di sicurezza (e perché non mi piace GET), ma come pubblicato da @Lee,

GET requests are used to retrieve resources, and PUT/POST are used to add/update 
resources so it would be completely against expectations for a RESTful API to use
PUT/POST to get data. 

Poiché verrà utilizzato da applicazioni di terze parti, è necessario seguire le buone pratiche per un servizio RESTful in modo che l'implementatore finale non venga confuso su questa parte.

Dovresti considerare tutte le eventualità plausibili, incluso l'utente che sta attivamente maliziosamente e (con successo) decodificando qualsiasi barriera di "sicurezza per oscurità".

Ma allo stesso tempo dovresti valutare l'impatto di un attacco di successo e la probabilità che si verifichi un tentativo. Ad esempio:

• Un servizio interno protetto da un firewall solido è meno soggetto ad attacchi rispetto a un servizio su Internet pubblico.

• L'impatto di qualcuno che abbatte un forum di discussione dei clienti è inferiore all'impatto con cui rubano le carte di credito dei clienti.

Il mio punto è che la "sicurezza totale" è "infinitamente costosa" ... e praticamente irraggiungibile. Idealmente dovresti prendere le tue decisioni su dove tracciare la linea sulla base di un'approfondita analisi costi-benefici.