Close

Security Headers in API Management

You can use outbound policies in API Management, to specify http security headers. Security headers should be part of the API response, that’s why you use outbound policies, not inbound policies. The exists-action should be set to “override” not “skip”, otherwise you accept the potentially wrong security headers when added by the client.

I’m not an expert on security headers, please refer to the link below and check missing headers. Looking at the research below I would say, checking http security headers doesn’t add extra security when calling the API from a logic app. On the other hand, I found posts on the internet that do check http security headers. Link: Protect APIs With Security Headers Using Azure API Management Policies 

The Strict-Transport-Security header forces the API to be accessed over the secure https protocol. This header should following the best practice time out after two years. Link: Strict-Transport-Security. Header is ignored when browser is accessing the site over Http. It has to be accessed via Https once. Expiration time will be updated every time the http header is returned to the client. Recommended setting Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

The content security policy specifies whether you trust the source of the content that is posted to a site. When you want to use it in the context of API Management, I would say the default-source can’t be set to ‘self’, since that would mean the content would only be allowed from the same domain. You could also set default-src to a specific website address, but that would not be correct either.  So, I wouldn’t specify the content-security-policy directive.

The Referrer HTTP request header contains an absolute or partial address of the page that makes the request. The Referrer header allows a server to identify a page where people are visiting it from. Again, I would say I can’t think of a reasonable specification in the context of API Management.

X-Frame-Options  indicates whether or not a browser should be allowed to render a page in a frame. I would say, not relevant in the context of API Management.

X-Content-Type-Options indicates that the MIME types advertised in the Content-Type header should be followed and not be changed. Value “nosniff” blocks a request if the request destination is of type style and the MIME type is not text/css, or of type script and the MIME type is not a JavaScript MIME type. Not relevant for API Management where the content-type is json or xml.

Feature Policy allows web developers to selectively enable, disable, and modify the behavior of certain features and APIs in the browser. So, this policy is also not applicable when an API is called from a logic app.

Alternative security header check from c-sharpcorner.com:

Note: exists-action should be set to “override”.