When settings up new API Management instances at customers, I notice that I often specify the same policies at the highest scope, All API’s.  This blog is just a small note to myself and hopefully it might help you too.

All APIs

Inbound policies

Two inbound policies are very common:

  • Delete the subscription key header in order not to disclose this to the backend API
    (preferably you rename this key to a technology agnostic name)
  • Allow CORS for the developer portal to work
<inbound>
   <set-headername="Ocp-Apim-Subscription-Key"exists-action="delete"/>
   <cors>
      <allowed-origins>
         <origin>https://***.developer.azure-api.net</origin>
      </allowed-origins>
      <allowed-methods>
         <method>GET</method>
         <method>POST</method>
         <method>PUT</method>
         <method>DELETE</method>
         <method>HEAD</method>
         <method>OPTIONS</method>
         <method>PATCH</method>
         <method>TRACE</method>
      </allowed-methods>
      <allowed-headers>
         <header>*</header>
      </allowed-headers>
      <expose-headers>
         <header>*</header>
      </expose-headers>
   </cors>
</inbound>

Outbound policies

The outbound policies are typically set to remove HTTP response headers that disclose information about the underlying technology.

<outbound>
   <set-header name="X-Powered-By" exists-action="delete" />
   <set-header name="X-AspNet-Version" exists-action="delete" />
</outbound>

Conclusion

Do you know other response headers that should be typically removed?  Please let me know in the comments section!  Any other common API Management policies?  Don’t hesitate to share them!!!

About me

Hi! I’m Toon Vanhoutte, a hands-on Azure architect – based in Belgium – with a big passion for teaching and helping people out. I’m happy to assist you during your Azure journey with high-quality advisory and I would love to teach you Azure’s possibilities via my tailored training courses.

Subscribe to the blog