CODEWITHSUNDEEP
apihttphttp-headers
Justin
Justin

Reputation: 45350

Set Strict-Transport-Security header for API

Does it make sense to set the Strict-Transport-Security header for API responses (i.e. requests that don't maintain state) and most likely don't originate from browsers.

Upvotes: 10

Views: 20311

Answers (2)

jsisodiya
jsisodiya

Reputation: 61

HSTS is generally a browser only instruction. Other callers, such as phone or desktop apps, do not obey the instruction. Even within browsers, a single authenticated call to an API over HTTP has risks on insecure networks. The secure approach is to configure API projects to only listen to and respond over HTTPS.

Ref:https://learn.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-5.0&tabs=visual-studio

Upvotes: 3

ethicalhack3r
ethicalhack3r

Reputation: 1132

The HSTS RFC does not mention APIs unfortunately.

Under 2.1 Use Cases it states:

o  Web browser user wishes to interact with various web sites (some
  arbitrary, some known) in a secure fashion.

o  Web site deployer wishes to offer their site in an explicitly
  secure fashion for their own, as well as their users', benefit.

https://www.rfc-editor.org/rfc/rfc6797#section-2.1

As it explicitly states "web browser" I think it is safe to assume that HSTS was designed for resources accessed via a web browser.

If you think your API may be used by web browsers in the future then I'd recommend adding the HSTS header. If your API will never be accessed via a web browser then you don't need the HSTS header, however, it may be worth adding it to 'future proof' your API incase you decide it should be accessed via a web browser in the future (and/or you allow HTTP connections in the future).

Upvotes: 7

Related Questions