Protezione di un'API privata visibile su Internet pubblica

Risposta rapida: non è affatto sufficiente per proteggere la tua API. Ognuno di questi passaggi presenta dei punti deboli che non sono stati risolti nel metterli insieme. La buona crittografia è difficile, e cerca di non reinventare la ruota.

Https - impedirà che le chiamate esatte siano visibili durante il transito. Ma non alla fine dell'utente, o ad un attacco "uomo nel mezzo".

Nascondi un numero - cerca "sicurezza per oscurità". Tl; Dr non fare affidamento su questo. Mai.

Passa un token buono per un'ora - sembra aperto a ogni forma di furto e intercettazione dell'autenticazione sul pianeta. Come fai a sapere che il token non viene utilizzato in modo improprio o utilizzato da qualcosa tranne il cliente previsto? Non lo fai.

1. Più difficile da implementare, più lavoro.

2. I clienti possono semplicemente accedere agli strumenti di sviluppo di Chrome e andare in Rete per vedere dove viene inviata la richiesta.

Questo è quello che faccio per proteggere la mia api. Costruisco con uno stack MEAN e ho usato i token Web JSON. Io uso una libreria chiamata passport.js per autenticarsi. Ecco come proteggo:

Diciamo che ho una rotta API come tale:

UserRoutes.post('/message', Middleware.verifyToken, function(req, res) {
      //post message and save to DB
});

Avviso ho usato Middleware.verifyToken sopra nel "mezzo". Questo viene chiamato dalla classe seguente

Quindi ho un file da qualche altra parte chiamato Middleware.js e all'interno di un metodo:

verifyToken: function() {

//grabs the json web token from the authorization header and verifies its valid. //If it is valid then continue will the route logic

}

Quindi questi sono i passaggi:

1. Assegna a un utente un token Web Json quando accedono (io memorizzo il mio in LocalStorage) (ho usato le librerie: jsonwebtoken, passport-jwt, passport, bcrypt).
2. Implementa una funzione middleware che verificherà il token. Ciò assicurerà che token / utente sia valido prima dell'esecuzione della logica effettiva del percorso.

Il concetto generale è che l'utente deve presentare un token web JSON valido ad ogni richiesta e questo token viene controllato prima che venga eseguita la logica del percorso. Se non è valido o non esiste, il percorso non verrà eseguito ed è possibile restituire un errore a chiunque abbia effettuato la richiesta.

Ci sono voluti circa un mese o due per essere in grado di implementare completamente questo sistema perché mi ci è voluto un po 'per imparare e capire passport.js e middleware, ma una volta fatto è stato grandioso e vale sicuramente il tempo necessario per imparare.

Ricerca: middleware, JSON Web Tokens e Passport.js

link
link

La mia analisi:

1. Use HTTPS for all requests.
2. Don't tell anyone the address of the API (I know I probably shouldn't rely on this)
3. Send an access key and a secret key to the API and the API sends back a token that is valid for 1 hour. (Maybe less)

1. Devi attivare un'intestazione HSTS per assicurarti veramente di utilizzare HTTPS per tutte le richieste
2. Sicurezza attraverso l'oscurità. Perché non ci metti solo una password? Nota: assicurati di memorizzare la password in modo sicuro utilizzando bcrypt e un salt. Ecco un'eccellente spiegazione di Tom Scott. Chiunque può vedere l'URL aprendo gli strumenti di sviluppo e andando a richieste.
3. Forse sicuro, a seconda di come lo si implementa. Non provare a implementare la tua suite crittografica. È una cattiva idea davvero .