Protezione di un'API di segnalazione degli errori contro lo spamming

2

Stiamo pianificando / specando un'API REST per la comunicazione con un'app iOS che un team esterno sta creando. Per la maggior parte delle chiamate, la chiave API è codificata nell'applicazione e un ID di sessione prodotto sul nostro lato dopo l'autenticazione dell'utente, altrimenti la chiamata viene ignorata (401, 403 o simile).

C'è un endpoint che stiamo pianificando, tuttavia, per la segnalazione degli errori. Gli errori nell'app possono verificarsi durante l'autenticazione e se vogliamo utilizzare questo endpoint per ricevere rapporti su questi, questa chiamata non può richiedere un ID di sessione.

L'obiettivo, e la domanda, è trovare un modo per rilevare e ignorare lo "spam" da parte di aggressori che hanno annusato l'API e lo hanno bloccato con rapporti inutili. So che questo non impedirà un DoS completo poiché l'API deve digerire la chiamata per determinare se è legittima, ma ridurrà l'inquinamento dell'archivio di registrazione degli errori sui nostri server.

La risposta più semplice a cui posso pensare è, non usarla per errori di pre-autenticazione. Possiamo registrare i tentativi di autenticazione, passare o fallire, dal momento che riceviamo quelle chiamate, e se non riceviamo quelle chiamate dall'app, probabilmente non riceveremo neanche il rapporto di errore risultante.

Esistono buone alternative per consentire all'app di segnalare gli errori riscontrati prima dell'autenticazione utente riuscita, evitando comunque che questo metodo sia troppo aperto allo spamming?

    
posta KeithS 28.04.2016 - 18:50
fonte

0 risposte

Leggi altre domande sui tag