OWASP Secure Headers for Web Services

The important part of your questions is that it's a API and not a web application. The security needs for an API returning XML is very different from those of a webb application returning a mix of HTML, JS, etc.

So let's look at the headers one by one, with an API perspective:

• HTTP Strict Transport Security (HSTS)
  HSTS is in general a good thing that should be encouraged. It prevents SSL-strip attacks. But those are only possible when the user enters the URL (without protocol) into the URL-bar of a browser. That is not how you (normally) consume a SOAP API. So if all your URLs are hardcoded with HTTPS, the benefits of HSTS are slim.

• X-Frame-Options
  This controls if your page can be displayed in a frame or not, and is intended as a way to prevent attacks like clickjacking, etc. This is not an issue for an API (why would loading XML into a frame ever be beneficial to anyone...), so it is not an issue.

• X-XSS-Protection
  If you return XML (as a SOAP API does), there is no JS execution so XSS isn't really an issue. So this header isn't useful. (That doesn't mean you don't have to think about injection attacks, though.)

• X-Content-Type-Options
  This is used to prevent MIME type sniffing, which is mainly an issue when you serve files uploaded by users. Thats normally not what an API does, so I wouldn't worry about this one either.

• Content-Security-Policy
  This sets what can and can not be included in a HTML document. If you are serving XML that is of no interest. So again, not applicable.

See the pattern here? Most of the headers (possibly with the exception of HSTS) doesn't really apply to API:s because the threats they counter are not relevant for an API.

all of these headers have their pros. Some of them have their cons as well. TL;DR: Use HSTS and X-Content-Type-Options.

Long version: Normally, especially the two standards in your list are important. Those are "HSTS" as well as "CSP". Everything that starts with an X is not really a standard. It is useful though. To check weather you can use it in a specific anvironment or not you could try for the website Can I use.

Anyhow. The HSTS header enforces the use of HTTPS as a "Trust on first use"-Principle. So after an initial visit on your site some information is saved by the browser. After hat the client (browser) will enforce HTTPS even if the user types "http". Man in the middle attacks will be a lot harder then.

The "Content Security-Policy" (when used correctly) will enforce that scripts are only executed from *.js-files. Even further you can (and should) tell the browser to only load from your page. This really does not help you from my pov because you dont serve HTML.

Same story for X-XSS-Protection.

These won't harm but won't really help as well.

So as for X-Content-Type-Options the MDN says:

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.

This may not be required for you and I do not really see the use-case but since your Content Type is always some SOAPy stuff you don't really suffer fom using it.

From my experience HSTS is a standard that everyone should use. HTTP without TLS is really kind of outdated and HTTPS without HSTS is a lot less secure then it could be. So for all of my projects I think of HSTS as mandatory. Just a final warning: Be careful when thinking about preloading. That my really limit your options to change something afterwards.