Guarda, CORS non blocca sicuramente un utente malintenzionato in possesso delle credenziali.

si questo è certo, non era mia intenzione fare affidamento su CORS, difatti l'ho abilitato su tutte le origini senza problemi! :)

volevo dire, dato che per fare dei POST da ajax devo abilitare AllowCredentials() su CORS e settare withCredentials: true nella chiamata ajax perchè passo da un dominio ad un altro ed i POST hanno l'attributo [Authorize]

questo potrebbe esporre l'applicazione a livello di sicurezza?

se si ho pensato ad un action filter (v. punto 4) che verifica alcune cose, origine e host della richiesta per esempio, per maggior sicurezza, altrimenti posso cestinare l'action filter...!

termino qui lo giuro! grazie!

ciao, ho omesso di dire un particolare:
è vero che le action di inserimento e delete richiedono autenticazione, ma una action è GET, quella che recupera tutti i commenti e non richiede autenticazione in quanto si vuole che i commenti siano visibili anche agli utenti non autenticati; l'action filter permette di filtrare l'origine e l'host, verifica a db la corrispondenza di tenant- dominio e host, e permette la fuoriuscita di dati o meno. Se per ipotesi la richiesta fosse inoltrata da un dominio non registrato verrebbe rifiutata; è aggirabile? certo che si, perché come dici tu

...la tua action può essere invocata usando un client http qualsiasi (che può forgiare la richiesta a piacimento)

infatti se da Postman imposto gli header in un certo modo la richiesta viene accettata...

in sostanza non mi piaceva l'idea che qualcuno potesse richiamare una action, api, ecc. al di fuori dell'app e mi sarebbe piaciuto un controllo nel filter che verifichi incontrovertibile che la richiesta provenga solo da dove voglio io; ma se gli header possono essere riscritti da una applicazione client....

a posteriori mi è capitato di leggere qui e questo è stato di conforto sul fatto che, serva o meno, l'implementazione del filter sembra corretta
https://www.owasp.org/index.php/CORS_OriginHeaderScrutiny
Countermeasure
Option B: We can scrutiny the Origin header value on server side

il mio filter esegue i punti 1.2.3. non il punto 4. che in effetti però sembra essere il punto più interessante da implementare

ma comunque mi domando ancora se tutto questo serva davvero..?


ciao.

---

Modificato da teo prome il 15 novembre 2016 13.48 -

---

Modificato da teo prome il 15 novembre 2016 13.50 -

ciao, si buona l'idea del feed, sono d'accordo!

La cache dell'IP potrebbe tornarti utile per capire se ci sono client che stanno inviando troppe richieste nell'unità di tempo

infatti, anche perchè l'app è su Azure, e la richiesta di risorse si paga, in effetti quella era la mia preoccupazione maggiore.

grazie dei consigli, ciao