OWASP Secure Headers for Web Services

La parte importante de sus preguntas es que es una API y no una aplicación web. Las necesidades de seguridad para un API que devuelve XML son muy diferentes de las de una aplicación webb que devuelve una mezcla de HTML, JS, etc.

Así que echemos un vistazo a los encabezados uno por uno, con una perspectiva de API:

• Seguridad de transporte estricta de HTTP (HSTS)
  HSTS es en general una buena cosa que debe ser alentado. Previene los ataques SSL-strip. Pero eso solo es posible cuando el usuario ingresa la URL (sin protocolo) en la barra de URL de un navegador. No es así como (normalmente) consume una API SOAP. Entonces, si todas sus URL están codificadas con HTTPS, las ventajas de HSTS son escasas.

• Opciones de X-Frame
  Esto controla si su página se puede mostrar en un marco o no, y está pensada como una forma de prevenir ataques como clickjacking, etc. Esto no es un problema para una API (por qué cargar XML en un marco nunca será beneficioso para nadie). ..), por lo que no es un problema.

• X-XSS-Protection
  Si devuelve XML (como lo hace una API SOAP), no hay ejecución de JS, por lo que XSS no es realmente un problema. Así que este encabezado no es útil. (Sin embargo, eso no significa que no tenga que pensar en los ataques de inyección).

• Opciones de tipo de contenido X
  Esto se usa para evitar el rastreo del tipo MIME, que es principalmente un problema cuando se sirven archivos cargados por los usuarios. Normalmente eso no es lo que hace una API, así que tampoco me preocuparía por esto.

• Política de seguridad del contenido
  Esto establece lo que puede y no puede incluirse en un documento HTML. Si está sirviendo XML que no es de interés. Así que de nuevo, no es aplicable.

¿Ves el patrón aquí? La mayoría de los encabezados (posiblemente con la excepción de HSTS) no se aplican realmente a las API: s porque las amenazas que responden no son relevantes para una API.

todos estos encabezados tienen sus ventajas. Algunos de ellos también tienen sus contras. TL; DR: utilice HSTS y X-Content-Type-Options.

Versión larga: normalmente, los dos estándares en su lista son importantes. Esos son "HSTS" así como "CSP". Todo lo que comienza con una X no es realmente un estándar. Aunque es útil. Para consultar el clima, puede usarlo en un entorno específico o no, puede probar en el sitio web ¿Puedo usar ?

De todos modos. El encabezado HSTS impone el uso de HTTPS como un principio de "Confianza en el primer uso". Entonces, después de una visita inicial a su sitio, el navegador guarda cierta información. Después de esto, el cliente (navegador) aplicará HTTPS incluso si el usuario escribe "http". El hombre en los ataques medios será mucho más difícil entonces.

La "Política de seguridad del contenido" (cuando se usa correctamente) hará que los scripts solo se ejecuten desde archivos * .js. Aún más puedes (y debes) decirle al navegador que solo cargue desde tu página. Esto realmente no te ayuda desde mi punto de vista porque no sirves HTML.

La misma historia para X-XSS-Protection.

Esto no dañará, pero en realidad tampoco ayudará.

En cuanto a X-Content-Type-Options, la MDN dice:

  

El encabezado HTTP de respuesta de X-Content-Type-Options es un marcador utilizado por el servidor para indicar que los tipos MIME anunciados en los encabezados Content-Type no deben cambiarse ni seguirse. Esto permite optar por dejar de detectar el tipo de MIME o, en otras palabras, es una forma de decir que los webmasters sabían lo que estaban haciendo.

Esto puede no ser necesario para usted y realmente no veo el caso de uso, pero dado que su tipo de contenido es siempre algo SOAPY que realmente no sufre al usarlo.

Desde mi experiencia, HSTS es un estándar que todos deberían usar. HTTP sin TLS es realmente un poco anticuado y HTTPS sin HSTS es mucho menos seguro de lo que podría ser. Entonces, para todos mis proyectos, considero a HSTS como obligatorio. Solo una advertencia final: tenga cuidado al pensar en la precarga. Que mi realmente limite tus opciones para cambiar algo después.