Azure Function App Security Headers | Proxies.json

The aim of this post is to show the proxies.json file usage for the Azure Function Apps. It might be possible to use for different cases. For this case, the proxy will return some extra response headers from the function requests.

Security is one of the most important nodes in the application development process. To avoid security vulnerabilities, the application needs to have some security improvements. This post is going to touch on one of these improvements. It is Security Headers. It is possible to scan any application via

It is possible to add those response header parameters to the application’s startup.cs file in the classic .Net Core application. The proxies.json file can do the same thing for Azure function apps. Proxies can be created by Azure Portal as well but this post is not going to mention anything about the Azure portal.

The basic proxies.json file is like the following. This sample proxies.json file has one proxy but it is possible to add more than one proxy with different match conditions. The proxies.json file needs to be in the application’s root folder and also it should be added to the project .csproj file for the export process. If it does not add to the .csproj file, it is not possible to see changes on the response.

  "$schema": "",
  "proxies": {
    "functionsProxy": {
      "desc": [
        "Description for the proxy."
      "matchCondition": {
        "route": "/%Proxy_ApiPrefix%/{*restOfPath}"
      "backendUri": "%Proxy_ApiUrl%/%Proxy_ApiPrefix%/{restOfPath}",
      "responseOverrides": {
        "response.headers.Content-Security-Policy": "default-src 'self'; script-src: 'self'",
        "response.headers.Referrer-Policy": "no-referrer",
        "response.headers.Strict-Transport-Security": "max-age=31536000; includeSubDomains; preload",
        "response.headers.X-Xss-Protection": "1; mode=block",
        "response.headers.X-Frame-Options": "SAMEORIGIN",
        "response.headers.X-Content-Type-Options": "nosniff"

Let’s start to explain fields from proxies.json file. It is possible to find those explanations in the as well.

proxies: It is an array for the proxies. The sample array just has one item. It’s name is functionsProxy. To add multiple proxies, It is enough to create a new item in the proxies array.

desc: It’s description for the proxy. It might be good to add this field for big projects or multi-proxy cases.

functionsProxy: This is the sample proxy’s name. It is possible to use any string value in this field. Proxy1, Proxy2, Proxy3 etc.

matchCondition: It is an URL template for the proxy and when the request matches with this URL template, the proxy is working for the request. It is possible to allow the proxy for specific method types in this field as well. To allow specific method types, It is enough to add the following line after route definition. 

"methods": [ "GET" ]

backendUri: It is the URL for the actual request. Matched conditions are going to call this URL. This field is a template like matchCondition field.

responseOverrides: This field is the actual target for the post’s case. For matched conditions, It is adding new response parameters. It is possible to manipulate the response body as well.

%….% variables in the proxies.json file are coming from launch.settings.json file for the local environment. To use these variables in the azure environment, they should be defined in the configuration section. The sample for the launch.settings.json file;

"Proxy_ApiUrl": "http://localhost:2424",
"Proxy_ApiPrefix": "api"

To include the proxies.json file to the package, the following code block needs to be in the Project -> ItemGroup Tag. Ex:

<Project Sdk="Microsoft.NET.Sdk">   
       <None Update="proxies.json">

To add any additional information or any mistake you can contact with me via this post or article[at]cinarr[dot]com

See you in the next posts 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *