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.
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>
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>
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!!!