app service AZSK Azure NodeJS

Unobvious stuff about Azure services – App Service TLS termination

If you’ve worked with Azure for the last few years, you might’ve came across things that exist in documentation, but are not highlighted in the basic overview and can cause confusion after a late discovery ( I am not arguing that these things should be highlighted in the overview) – So I decided I should flag few occasions like this here;

Starting with subject of ’App Service TLS termination’ as there might be some compliance driven edge cases, where you might need to evaluate the other Azure Services. If you don’t have such edge cases, then App Service in terms of security is a excellent choice. Much better than for example than plain (read:unsecured) docker host in its default configuration running your application.

Background: Encryption in Azure (TL DR)

Due to my work being on the security side of things, I receive frequently questions about encryption. Sometimes these questions are driven more about compliance than actual technical security, which is one the aspects of security work. (Note this is not negative comment, compliance is another domain, with its own required domain knowledge)

  • My short take is that Azure goes beyond normal expectations in terms of encryption in transit and in rest. By going beyond, I mean, that you can audit/alert/getRecommendations/ and to some extent ’auto-fix’ these

App Service TLS termination

The In-transit traffic towards App Service Web app is not e2e (’end-to-end encrypted’). TLS terminates in another part of the service architecture, and requests to actual application runtime arrive as unencrypted. Even knowing this I prefer app service 99% of the time for deploying workloads in Azure.

  • My reasoning: Though this is not technically correct, I consider TLS Termination design of Azure App Service to be part of my application runtime, not an external service in terms evaluation of ’how well the application is secured’. In my thinking its similar to having NGINX container terminating traffic before reaching the application runtime with HTTP
  • Its also good to understand, that you can have multiple TLS terminating services before reaching appliction runtime: waf-HTTPS->apim-HTTPS->AppService->HTTP->ApplicationRuntime
  • If your app requires E2E encryption right until the application runtime due to compliance reasons, you might be better running your service in version that support the application runtime TLS termination
    • AKS
    • Docker Host in Azure (lot other things to secure here…)
    • ACI

Example: Node.JS application running in docker host vs app service web app

Below are code snippets of the relevant parts (not complete code)

  • With containerized version of the application which runs on a docker host (not as container in app service*) – The spawned express object is added as ’requestListener’ argument into node HTTPS server initialization function. In app service this wouldn’t work, even if it we’re running in custom port
  • With App service I’ve taken in consideration, that App service adds another TLS terminating layer into the service, so my application runtime is internally exposed by the app service

*The container option of App Service deployment supports terminating TLS in the container


If the TLS terminating design of app service is ok for you, and you want to increase security of the app service you should look the controls available in AZSK.

AZSK Table for App Service


Description & RationaleControlSeverityAutomatedFix Script
All users/identities must be granted minimum required permissions using Role Based Access Control (RBAC)
Granting minimum access by leveraging RBAC feature ensures that users are granted just enough permissions to perform their tasks. This minimizes exposure of the resources in case of user/service account compromise.
Custom domain with SSL binding must be configured for App Service
Use of custom domain protects a web application from common attacks such as phishing, session hijacking and other DNS-related attacks.
App Service must authenticate users using Azure Active Directory backed credentials
Using the native enterprise directory for authentication ensures that there is a built-in high level of assurance in the user identity established for subsequent access control.All Enterprise subscriptions are automatically associated with their enterprise directory ( and users in the native directory are trusted for authentication to enterprise subscriptions.
Publish profile credentials must not be used for App Service deployment
Publish profile of App Services contains deployment and FTP credentials. There are 2 risks with this. First, the credentials can get easily leaked during the various workflows involving the publish profile. Secondly, use of public profiles weakens auditability of deployment actions.
Trigger URL for the App Service Web Job must require authentication
Scheduled WebJobs can be triggered by specific scheduled time or by triggered URL. WebJob triggered URL can be authenticated by AAD authentication (bearer token) or by App Services deployment credentials. Since its not recommended to use publish profiles, WebJob triggered URL must be authenticated by AAD authentication.
The webhook used for a Web Job must encrypt sensitive data in transit
Use of HTTPS ensures server/service authentication and protects data in transit from network layer man-in-the-middle, eavesdropping, session-hijacking attacks.
All App Service secrets should be stored in Key Vault
Keeping secrets such as DB connection strings, passwords, keys, etc. in clear text can lead to easy compromise at various avenues during an application’s lifecycle. Storing them in a key vault ensures that they are protected at rest.
App Service should use Notification Hub for push notification (instead of directly using Push Notification Service)
Notification Hub provides a better mechanism to manage the keys related Push Notification Systems (PNS).
Remote debugging must be turned off for App Service
Remote debugging requires inbound ports to be opened on App Service. These ports become easy targets for compromise from various internet based attacks.
Web Sockets should be disabled for App Service
WebSockets protocol (WS) is vulnerable to different types of security attacks. Usage of Web Sockets with in web applications has to be carefully reviewed.
’Always On’ should be configured for App Service
By default, websites are unloaded if they have been idle for some period of time. However, this may not be ideal for ’high availability’ requirements. Configuring ’Always On’ can help prevent app services from getting timed out.
The latest version of .NET framework version should be used for App Service
Running on older .Net versions could mean you are not using latest security classes. Usage of such old classes and types can make your application vulnerable.
Deployment of App Service should be done using ARM template
Deployment using ARM template is more secure than using publish profiles. This is because the former uses user/SPN credentials which can be protected better than publish profiles and provide a better audit trail of deployment activity.
App Service must be deployed on a minimum of two instances to ensure availability
App Service deployed on multiple instances ensures that the App Service remains available even if an instance is down.
Backup feature must be configured to backup data for App Service
Enabling backup on App Service ensures that there is always a previous snapshot of App Service data that can be leveraged towards recovery scenarios.
Auditing and Monitoring must be enabled for App Service
Auditing enables log collection of important system events pertinent to security. Regular monitoring of audit logs can help to detect any suspicious and malicious activity early and respond in a timely manner.
Auto healing should be configured for App Service
With the use of Auto-Healing, a website can automatically recover from long running/blocked states. Auto-Healing enables automatic recycling of the worker process hosting your web application based on certain events. E.g. 1. When request count breaches a certain limit 2. When requests are running slower that expected 3. When an unexpected http status code is received X number of times 4. When the process consumes more than expected memory
App Service must only be accessible over HTTPS
Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks.
WEBSITE_LOAD_CERTIFICATES parameter must not be set to ’’ (i.e. all) for App Service
Using ” for this parameter means that all certificates will get uploaded to the VM running the website. This will most likely lead to abuse of the principle of least privilege as it is unlikely that the site needs access to all certificates at runtime.
Keys should be renewed after a regular interval
Periodic key/password rotation is a good security hygiene practice as, over time, it minimizes the likelihood of data loss/compromise which can arise from key theft/brute forcing/recovery attacks.
Host key access should not be shared with individual clients
Host Keys grant full access to all the functions within a function app. Not sharing this key with individual clients ensures that clients are granted just enough permissions to invoke a particular function
Authorization level for HTTP Trigger function in a function app should be set to ’Function’
Use ’Function’ authorization level to ensure that users with minimum of function keys should only be able to invoke the function. This is in accordance with the principle of least privilege.
Functions app edit mode should be set to Read Only
Using ’Read Only’ mode ensures that source code is changes come in via a CICD pipeline and not directly through portal. This ensures that code changes are properly audited.
Different functions keys must be generated and shared with individual clients.
Different function keys for individual clients promotes separation of concerns. It also makes revocation easier to manage in the event of a compromise of one client.
Ensure that CORS access is granted to a limited set of trusted origins.
CORS enables applications running under one domain to access a resource under another domain. Using ’*’ (allow all) for CORS setting means that an application running under any domain can have access to your application’s resources and data. Restricting allowed origins to the specific set that needs access aligns with the principle of least privilege.
Alerts should be configured to track unauthorized access attempts for the AppService.
Alert rules for unauthorized requests enable you to detect any suspicious and malicious activity early enough.
Use Managed Service Identity (MSI) for accessing other AAD-protected resources from the app service.
Managed Service Identity (MSI) allows your app to easily access other AAD-protected resources such as Azure Key Vault. The identity is managed by the Azure platform and eliminates the need to provision/manage/rotate any secrets thus reducing the overall risk.
Function App must only be accessible over HTTPS
Use of HTTPS ensures server/service authentication and protects data in transit from network layer eavesdropping attacks.
Use approved version of TLS for the App Service
TLS provides privacy and data integrity between client and server. Using approved TLS version significantly reduces risks from security design issues and security bugs that may be present in older versions.
Extensions installed on a App Service should be carefully reviewed
Each extension is something like a plugin that adds functionality to your App Service. Installing unknown/unverified extensions can be dangerous as some third party extensions may have vulnerabilities which introduce unnecessary avenues for attack.
Setup IP-based access restrictions for App Service if feasible
Using the IP/VNet subnet rules based access restriction ensures that access to the data or the service is restricted to a specific set of IPs. NOTE: While this control does provide an extra layer of access control protection, it may not always be feasible to implement in all scenarios.
MediumYes No
Review use of credentials in CORS request for App Service
CORS enables applications running under one domain to access a resource under another domain. Allowing cross-origin credentials is a security risk. A website at another domain can send a signed-in user’s credentials to the app on the user’s behalf without the user’s knowledge.

Till next time!

0 comments on “Unobvious stuff about Azure services – App Service TLS termination


Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

Olet kommentoimassa -tilin nimissä. Log Out /  Muuta )


Olet kommentoimassa Facebook -tilin nimissä. Log Out /  Muuta )

Muodostetaan yhteyttä palveluun %s

%d bloggaajaa tykkää tästä: