La mia interfaccia utente deve essere protetta se la mia API è?

Se la tua API è solida, la vera vulnerabilità si riferisce al fatto se puoi essere certo che l'utente è chi dicono di essere.

Un vettore di attacco è chiamato falsificazione di richieste tra siti ("CSRF" o "XSRF"). In pratica, qualcuno che impersona un altro utente e fa richieste al tuo server.

Quando stabilisci una sessione (che contiene i ruoli per un determinato utente), devi assicurarti che nessun altro possa dirottare quella sessione. In genere ciò avviene impostando un cookie univoco sulla macchina dell'utente che è " link " (ovvero, un cookie che il cliente -side JS non dovrebbe essere in grado di manipolare), quindi assicurarsi che quel cookie sia lo stesso nelle richieste successive.

Ecco un modulo Node destinato a rafforzare il server Web con la protezione CSRF, tra le altre misure di sicurezza, che potrebbe essere utile osservare: collegamento

Re: l'API in particolare, ecco una rottura di qualcuno che ha hackerato GitHub .

Probabilmente va oltre le tue esigenze di sicurezza, ma tieni presente che qualsiasi nefasta estensione di Chrome con le giuste autorizzazioni può alterare il lato client in modo tale da infrangere il tuo modello di sicurezza (inviando dati fuori sede o modificando il Interfaccia utente, ad esempio).

Penso che tu sia sulla strada giusta. Finché l'API è sicura e non consentirà un comportamento scorretto, non è possibile manipolare l'interfaccia utente per causare comportamenti errati direttamente, almeno per quanto riguarda l'applicazione.

I problemi iniziano quando ti rendi conto che dal punto di vista dell'utente non è possibile fidarsi dell'interfaccia utente. Se è possibile manipolare ciò che l'utente vede, allora potrebbe essere possibile indurli a inserire informazioni errate ingannando il loro input. Allo stesso modo, la perdita di informazioni dall'interfaccia utente può o non può essere un problema nel tuo contesto.

Non dovrai preoccuparti degli exploit in blocco che infrangono le regole di business, dal momento che l'API non lo consente, ma hai ancora problemi di sicurezza per l'esperienza dell'utente finale.

In teoria è sufficiente che solo l'API sia sicura, come nel caso delle tipiche applicazioni client-server in cui l'utente utilizza un client di sua scelta ed è il problema dell'utente se il client è sfruttato.

Tuttavia, nel caso di un sito Web, dal momento che stai fornendo il client (l'interfaccia web), spetta a te assicurarti che non possa essere sfruttato da terze parti una volta che l'utente ha effettuato l'accesso utilizzando tecniche come XSS e CSRF.

Sfortunatamente, non è possibile limitare le informazioni da un utente in modo efficace una volta arrivato al computer client. In altre parole, se comprendo correttamente che stai inviando un file JS con codice o informazioni che non vuoi che l'utente sia in grado di leggere a meno che non abbia ruoli specifici, allora non sarai in grado di raggiungere quell'obiettivo . Sarà necessario filtrare le informazioni sul lato server prima di inviarle al client. Questa operazione può richiedere molto tempo per controllare sempre i ruoli utente prima di inviare i dati. Ciò richiede più chiamate al server poiché l'utente esegue determinate attività che richiedono informazioni. Ma tali azioni sono necessarie per garantire che le informazioni siano accessibili solo agli utenti corretti.

Il js minimizzato non fornisce molto offuscamento una volta che è stato inviato all'utente.