È necessario disinfettarlo come se fossero dati inseriti dall'utente. Non ha bisogno di essere malvagio dal provider API o potrebbe anche essere colpa dell'utente che fornisce i dati al provider API. Chi dice che il provider API ha disinfettato i dati? Chi dice che il provider dell'API deve disinfettare allo stesso modo come te? Forse il personaggio speciale è valido per lui.
Un "" "potrebbe essere un carattere valido per il provider API e un nome di persona potrebbe essere chiamato" Robert "); DROP TABLE studenti; -" e hai iniettato SQL senza intenzioni malvagie del provider API ma da un mamma ha chiamato suo figlio in questo modo.
Per un altro esempio puoi ottenere dati da un provider API e visualizzarli sul tuo sito web e non sanatizzarli: potrebbe contenere un carattere speciale che interrompe la tua pagina web o l'intero sito web. Potrebbe contenere codice javascript / html male che può infettare il computer dell'utente con un virus.
Potrebbe contenere codice javascript / html male che ha gli stessi diritti dell'utente che lo visualizza. Un amministratore loggato visualizza la pagina e javascript cancella o manipola il sito Web / crea un nuovo utente con admin admin / molte altre cose.
A seconda di come i dati API vengono memorizzati / elaborati, potrebbe leggere / scrivere file rilevanti per la sicurezza sul sistema o creare / modificare file eseguiti sul server. Ad esempio, è possibile creare un file che viene eseguito dal server web anziché inviato direttamente al client.
Quindi, sempre sanatizza i dati di terze parti.
Modifica per assicurarti che non ci siano equivoci: sto parlando di dati nel significato della rappresentazione di informazioni, non di informazioni di per sé. L'informazione sarebbe che un'attrice è la mamma di Robert. La rappresentazione delle informazioni potrebbe essere
{actress: "Robert's mum"}
Quindi assicurati che questi dati non causino un'iniezione SQL al tuo fianco. Se ti fidi delle informazioni che l'attrice era davvero la mamma di Robert è un altro argomento.