OWASP Secure Headers per i servizi Web

La parte importante delle tue domande è che si tratta di un'API e non di un'applicazione web. Le esigenze di sicurezza per un XML di ritorno dell'API sono molto diverse da quelle di un'applicazione webb che restituisce un mix di HTML, JS, ecc.

Quindi esaminiamo le intestazioni una per una, con una prospettiva API:

• HTTP Strict Transport Security (HSTS)
  L'HSTS è in generale una buona cosa che dovrebbe essere incoraggiata. Impedisce gli attacchi con strip SSL. Ma questi sono possibili solo quando l'utente inserisce l'URL (senza protocollo) nella barra degli URL di un browser. Questo non è il modo in cui tu (normalmente) consumi un'API SOAP. Pertanto, se tutti i tuoi URL sono hardcoded con HTTPS, i vantaggi di HSTS sono ridotti.

• X-Frame-Options
  Questo controlla se la tua pagina può essere visualizzata in una cornice o no, ed è intesa come un modo per prevenire attacchi come il clickjacking, ecc. Questo non è un problema per un'API (perché caricare XML in una cornice è sempre vantaggioso per chiunque. ..), quindi non è un problema.

• X-XSS-Protection
  Se restituisci XML (come fa un'API SOAP), non c'è alcuna esecuzione JS quindi XSS non è davvero un problema. Quindi questa intestazione non è utile. (Ciò non significa che non devi pensare agli attacchi per iniezione, però.)

• X-Content-Type-Opzioni
  Questo è usato per prevenire lo sniffing del tipo MIME, che è principalmente un problema quando servi i file caricati dagli utenti. Normalmente non è ciò che fa un'API, quindi non mi preoccuperei neanche di questo.

• Content-Security-politica
  Questo imposta ciò che può e non può essere incluso in un documento HTML. Se stai servendo XML che non interessa. Quindi, di nuovo, non applicabile.

Vedi lo schema qui? La maggior parte delle intestazioni (eventualmente con l'eccezione di HSTS) non si applica realmente alle API: s perché le minacce che contrastano non sono rilevanti per un'API.

tutte queste intestazioni hanno i loro professionisti. Alcuni di loro hanno i loro svantaggi. TL; DR: usa HSTS e X-Content-Type-Options.

Versione lunga: normalmente, in particolare, i due standard nell'elenco sono importanti. Quelli sono "HSTS" e "CSP". Tutto ciò che inizia con una X non è davvero uno standard. È utile però. Per controllare il tempo è possibile utilizzarlo in un determinato ambiente o non provare per il sito web Posso usare .

In ogni caso. L'intestazione HSTS impone l'uso di HTTPS come "Trust on first use" -Principle. Quindi, dopo una visita iniziale sul tuo sito, alcune informazioni vengono salvate dal browser. Successivamente, il client (browser) imporrà l'HTTPS anche se l'utente digita "http". L'attacco dell'uomo nel mezzo sarà molto più difficile di allora.

Il "Content Security-Policy" (se utilizzato correttamente) imporrà che gli script vengano eseguiti solo da * .js-files. Inoltre è possibile (e dovrebbe) dire al browser di caricare solo dalla tua pagina. Questo in realtà non ti aiuta dal mio pov perché non offri HTML.

Stessa storia per X-XSS-Protection.

Questi non danneggeranno ma non saranno di grande aiuto.

Quindi, come per X-Content-Type-Options, l'MDN dice:

The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This allows to opt-out of MIME type sniffing, or, in other words, it is a way to say that the webmasters knew what they were doing.

Questo potrebbe non essere richiesto per te e non vedo realmente il caso d'uso, ma dal momento che il tuo Content Type è sempre un materiale SOAPy che non soffri davvero per usarlo.

Dalla mia esperienza, HSTS è uno standard che tutti dovrebbero usare. HTTP senza TLS è davvero obsoleto e HTTPS senza HSTS è molto meno sicuro di quanto potrebbe essere. Quindi per tutti i miei progetti penso che l'HSTS sia obbligatorio. Solo un avvertimento finale: fai attenzione quando pensi al precarico. Che in realtà limiti le tue opzioni a cambiare qualcosa in seguito.