How to Secure Backend api app in Azure App Services

Kuldeep Singh(OT) 60

Hi Team, we use Azure Managed Service - Azure web app and api app for application deployment on azure.

Frontend apps are hosted on web app and they are publicly accessible.

Backend api are hostend on api app its also publicly accessible.

then in last we have DB, which listen from Backend apis.

My concern is that how can i secure my backend api app, so that i can be only accessible via frontend apps.

one Method i found to use cors, but to use cors but then devloer can access the api directly.

Can anyone suggests me what we can do best here to achieve security and also devloper work not get stopped.

1 answer

Ben Gimblett 3,840 Reputation points Microsoft Employee

2024-06-24T10:45:11.1133333+00:00

Hi - Thanks for the question
CORS is about cross origin management (http and requests to different domains)

In this context you can consider a few things

But there's two things you should always ensure.
(1) End to end transport security - each hop is over TLS etc
(2) Strong auth - either cert or oauth2

Options
(1) Use the outbound Ips of the frontend App and access restrictions on the backend API (this is only necessary when the apps are not on the same plan or where the plans are not showing the same outbound Ips (meaning they're on the same webspace/stamp)
However the problem with this is that you are "allow listing" not only your traffic but also other users of the same webspace/stamp.
One alternative is to host single tenant (App Service Environment v3) but this is expensivre
Another is to VNET integrate the web app to a subnet in a VNET and use a AZ NAT Gateway
(but again this adds cost)

(2) VNET Integrate the front end to a VNET subnet (again, this is for outbound calls ) and have both API and DB answer on a private endpoint - you would need to disable public access for both - if using Az PaaS this is via the software firewall (Web App = Access restrictions, SQL DB PaaS for example also has a software firewall)
There is a small cost associated with Private endpoints

(3)
A variation on the above is to VNET integrate the front end but use "Service Endpoints" on that subnet locking the public endpoint for both API and DB to the front ends VNET Subnet on the public endpoint of each
This avoids the small private endpoint charge but in theory you still address on a public IP for the API and DB both - it's just that they wont accept traffic from anywhere but your front end as controlled by the software firewall for each

I can provide you some doc links - so let us know if you have further queries on any of the above by using the comments
Please sign in to rate this answer.
Kuldeep Singh(OT) 60 Reputation points

2024-06-25T11:49:06.9666667+00:00

@Ben Gimblett PLease find my comment.

(1) End to end transport security - each hop is over TLS etc- Each hope is over tls, we are using azure paid app service certificates for applications.

(2) Strong auth - either cert or oauth2 - Its mangaged by Dev but we should have something at infra level to protect api app.

Options

(1) Use the outbound Ips of the frontend App and access restrictions on the backend API - you have already mentioned its limitation so it is not useful.

Another is to VNET integrate the web app to a subnet in a VNET and use a AZ NAT Gateway (but again this adds cost) - i have tried this but its not help in secure comm. bet frontend to backend subnet.

VNET Integrate the front end to a VNET subnet (again, this is for outbound calls ) and have both API and DB answer on a private endpoint - you would need to disable public access for both - if using Az PaaS this is via the software firewall (Web App = Access restrictions, SQL DB PaaS for example also has a software firewall)

There is a small cost associated with Private endpoints

The above recommendation only work when user request comes from same network but thats not possible, user can access the frontend from all over the world and its request never reach to app service.

3 A variation on the above is to VNET integrate the front end but use "Service Endpoints" on that subnet locking the public endpoint for both API and DB to the front ends VNET Subnet on the public endpoint of each

This avoids the small private endpoint charge but in theory you still address on a public IP for the API and DB both - it's just that they wont accept traffic from anywhere but your front end as controlled by the software firewall for each

this point is not clear, if you can explain more or share some relevant doc around it.

Ben Gimblett 3,840 Reputation points Microsoft Employee

2024-06-25T12:05:15.24+00:00

Bg: "Another is to VNET integrate the web app to a subnet in a VNET and use a AZ NAT Gateway (but again this adds cost) "

You: "i have tried this but its not help in secure comm. bet frontend to backend subnet."

Bg: "It does, because with the client app going through a IP or set of IPs you control (natgw) you can secure just your traffic at the IP level using the api access restrictions (software firewall).
BUT given the client is required to be VNET integrated then service endpoints or private endpoints are a better approach here"

Ben Gimblett 3,840 Reputation points Microsoft Employee

2024-06-25T12:08:14+00:00

bg: "...There is a small cost associated with Private endpoints"

You: "The above recommendation only work when user request comes from same network but thats not possible, user can access the frontend from all over the world and its request never reach to app service."

Remember that the client traffic into the app service web app for the front end can be served via the front end - or even through front door and onto the client web app (either directly, or via private endpoint) which would improve end user experience (at extra cost and complexity to you)

But the idea here is to restrict backend API and DB so neither is publicly accessible
By adding the client app to the vnet for OUTBOUND traffic only then using a private endpoint for both API and DB you're keeping the traffic between client, API and DB private whilst still allowing the client to be served publicly. Again, either directly or via Front Door, cloud flare or some other edge proxy/CDN.

Ben Gimblett 3,840 Reputation points Microsoft Employee

2024-06-25T12:11:20.6866667+00:00

There are a few articles talking about protecting backend for web apps - but this one https://azure.github.io/AppService/2021/04/22/Site-with-secure-backend-communication.html is quite good. Mads talks about Key Vault and Cognitive services but this could just as easily be an API and Database or any backend . The only requirement is the backend supports private endpoint

Ben Gimblett 3,840 Reputation points Microsoft Employee

2024-06-25T12:14:45.9633333+00:00

To illustrate the aside above about better catering for GLOBAL customer traffic into you client web app:

The following link talks about using Az front door to proxy client traffic from the edge/CDN onto a client web app (the above would still apply for protecting the web apps backend)

https://learn.microsoft.com/en-us/azure/frontdoor/private-link

Note: You dont have to do it this way - you can use Front Door Standard and access restrictions in the app service client - to restrict by front door service tag and FDID header REF https://learn.microsoft.com/en-us/azure/app-service/overview-access-restrictions#restrict-access-to-a-specific-azure-front-door-instance

Kuldeep Singh(OT) 60 Reputation points

2024-06-25T12:24:11.9166667+00:00

Please find pic for reference, and suggest sol, am ok with cost of private endpoint or even application gateway but i have tried them they solving my purpose.

Ben Gimblett 3,840 Reputation points Microsoft Employee

2024-06-25T13:06:51.2133333+00:00

Hi - The key part here is the client virtual network integration for outbound calls (that would of course include to the api / database - could also include key vault etc)

Normally this is not part of a network, but with vnet integration you can associate web app to a vnet subnet to have control - then outbound calls behave same as a VM

REF https://learn.microsoft.com/en-us/azure/app-service/configure-vnet-integration-enable

Please read carefully RE limitations etc. Right now it's 1 subnet for each app plan which can lead to a proliferation of subnets - but this is changing

Ben Gimblett 3,840 Reputation points Microsoft Employee

2024-06-25T13:08:36.1+00:00

I would assume the front end and backend app is at least on a different "web app".

If you share the plan it's OK but you wont be able to differentiate traffic by source ip as the traffic for both apps (as they share a plan) would address on the linked subnet prefix

So , if this is important you need client web app on App Service Plan A and api web app on App Service Plan B

This implicitly increases cost.

It really depends whether you want to say "I will only allow client traffic to the api and only allow the api to the database never the client directly to the database" in this case you need two subnet which means you need two plans

Kuldeep Singh(OT) 60 Reputation points

2024-06-25T13:51:50.81+00:00

i have two diff plan, one frontend frontend and one for api cost is not issue here, but api should not be publicly asseible thats my concern still.

Ben Gimblett 3,840 Reputation points Microsoft Employee

2024-06-25T14:20:52.83+00:00

private endpoint presents a different path. both private and public endpoint can be used at the same time - with NSG controlling PE ingress and "access restrictions" controlling public endpoint access
Sign in to comment

Share via

How to Secure Backend api app in Azure App Services

1 answer