Securing and Configuring Web Apps In Azure: Start To Finish

Web applications make up a lot of the traffic on the internet, ranging from serverless services like Azure Web Apps and Static Sites to containers and Kubernetes Services running frontend apps to WebAssembly (Wasm) running browser-based stacks.

Because there are so many methods of running them and, therefore, very large stacks running as web apps, understanding the key differences between the implementation of load-balanced traffic, security, and scalability is crucial as there are a lot of different options with minor differences between each that may be important to your environment.

In this blog post, you’ll learn about a few key breakdowns between web apps, static websites, scalability, CDN/global solutions, and how to secure it all from known attacks.

Prerequisites

For the purposes of following along with this blog post from a hands-on perspective, you'll need the following:

1. An Azure account. If you don't already have one, you can sign up for a free 30-day trial here.
2. An app to deploy. If you don't already have one, you can use the test Angular app found here.

If you don't want to follow along from a hands-on perspective, that's totally fine! Reading through the blog post will still be great for you from a theoretical perspective so you can get a clear understanding of how it all works.

Web Apps vs Static Sites (Static Web Apps)

Aside from the technical understanding of static web apps, app services, Front Door, app gateway, and WAF, there’s a need to understand what each does as the difference are slight, but the impact may be large. In the first section, let’s break down web apps and static websites.

App Services is for full-blown web APIs. It has a ton more options in terms of flexibility and scalability.

Four good examples of flexibility within app services are:

1. Database integration.
2. Continuous Deployment.
3. Authentication and Authorization.
4. Deployment via code or container.

A good way to think about App Services is that it's a place to run a full-blown web API, not just a static website.

A Static Web App, on the other hand, is for Static web pages. You’ll usually see Static Sites for a single page application from code repos. For example, a lot of sites running Angular are on Static Sites. When creating a Static Web App, you'll have the choice to deploy from a Git repo of your choosing along with some services like Enterprise Grade for a managed Front Door. The purpose of a Static Web App is to be simple, so you won't get as many capabilities as a standard App Service, but you may not need them (it all depends on what you're building).

Enterprise Grade vs Front Door

Static web apps enterprise grade is like a managed version of Front Door. If you want flexibility and configuration capabilities, implementing Front Door by itself makes the most sense. If you want a seamless method of implementing Azure Frontdoor and don’t need the flexibility and management, use Static Web Apps Enterprise grade.

The problem is that when you create a WAF (more on that configuration later), it’ll look for either a Front Door or an App Gateway. If you use Enterprise Grade (with a built-in front door), WAF won’t see that as a “true” Front Door, so you’ll have to create one anyway.

App Gateway vs Front Door

Front Door vs Front Door Profile

Per the definition from the Microsoft docs: "Azure Front Door is a globally distributed, multi-tenant service that acts as a scalable and secure entry point for web applications, while a Front Door profile is a specific configuration for your application, allowing you to customize its behavior and routing."

When you create a Front Door, there will always be a "default" Profile. You can then create new Profiles based on the rules you'd like to implement for your application stack (endpoints and routing protocols).

Web Application Firewall (WAF)

After your Web App is created and the Front Door/CDN is configured to sit in front of your application, it's time to ensure that it's as secure as possible. One method of doing that by default is implementing a WAF.

A WAF is an out-of-the-box method of protecting web apps by default. There are configurations implemented as soon as you deploy it that include protecting against XSS attacks and other OWASP-centric security implementations that you don't have to worry about implementing manually. You can also implement your own rules.

If you deploy Front Door, deploy with Premium the SKU because it looks like if you choose Standard and your WAF is Premium, you won’t be able to choose the WAF during the Front Door configuration.

Static Web App Enterprise Grade vs WAF

Static Website Enterprise Grade is used to:

• Implement a managed Front Door
• CDN
• Global distribution

A WAF is used to:

• Enable by default best security practices.
• Give you the ability to prevent or detect issues
• Create, manage, and implement rules (like threat detection)

In short, Enterprise Grade in a Static Web App is a managed Front Door. A WAF is security out of the box that implements best practices from frameworks like OWASP.

Deploying The Environment

Now that you know about the various services and how they all work, let’s implement a stack. The instructions below are what you’ll use along with some explanations as to why.

1. Create a Static App Service.
   1. with or without enterprise grade
      1. The problem is that when you create a WAF, you can use a Front Door or an App Gateway. If you use Enterprise Grade (with a built-in front door), WAF won’t see that as a “true” Front Door, so you’ll have to create one anyway. With that being said, it’s not worth the money to pay for Enterprise Grade if you’re going to use a WAF.
2. Create the WAF
   1. Use the Front Door option
   2. During the creation process, there’s an association tab that you can use to attach the Front Door Profile you attached in the previous section.
3. Create a Front Door with Premium SKU
   1. If you choose Standard and your WAF is Premium, you won’t be able to choose the WAF during the Front Door configuration.
   2. Attach it to the Static Web App and ensure a Front Door Profile exists.
4. Test with ZAP
   1. Run ZAP against the Front Foor.
   2. Go to the Front Door you created and drill down into Metrics.
   3. Within metrics, search for Web Application Firewall Request Count.
   4. Should see results of the test.

Create A Static Web App

1. Log into the Azure portal and search for App Services. You'll then click the blue +Create button and choose Static Web App.

2. Input your subscription, resource group name, and the name of the Web App.

You'll also choose the hosting plan along with where your code base exists that you wish to deploy. Choosing the Standard plan will work for testing purposes.

3. Choose the Git organization where the code base exists along with the repository and the branch.

Once complete, click the blue Review + create button.

To create a Static Web App with the Azure CLI, you can use the following:

az staticwebapp create --name <your-static-web-app-name> \
--resource-group <your-resource-group-name> \
--location <your-azure-region> \
--source <your-github-repo-url> \
--branch <your-github-branch>

Create A WAF

1. Log into the Azure portal and search for WAF. Once you're in the WAF service, click the blue + Create front door WAF policy button.

2. Ensure to choose the Front Door option along with the proper tier, subscription, and name for the policy.

If you leave the default Premium tier, ensure that the Front Door is premium as well. Otherwise, the WAF won't come up when you create the Front Door.

3. You have two options - Detection and Prevention. Detection will tell you the issues that occur within your web app and Prevention will let you know the issues and stop them from happening. Choosing Detection for the purposes of this blog post is fine.

4. As you'll see on the Managed rules tab, those are the security rules that come out of the box.

5. You can leave the other options as default. When ready, click the blue Review + create button.

Front Door Creation

1. Within the Azure portal, search for Front door. When you're at the Front Door service, click the blue +create button.

2. Leave the offering section as the default, but I encourage you to take a look at the custom create offering to get an idea on the differences.

3. Input the appropriate subscription, resource group name, and name of the Front Door along with ensuring that Premium is chosen.

4. Specify the Static Web App that you created.

5. Attach the WAF policy.

Once complete, click the blue Review + create button.

To create a Front Door with the Azure CLI, you can use the following:

az afd profile create \
--profile-name NAME_OF_PROFILE \
--resource-group NAME_OF_RG \
--sku Premium_AzureFrontDoor

Test The Web App

The final step is to test the application and confirm that the security policies via WAF are working as expected.

There are a few different tools you can use to do this. In this case, you can use OWASP ZAP, which you can find for free here.

To use OWASP ZAP, put the URL of your Front Door within ZAP and run an attack.

Within metrics via the Front Door, search for Web Application Firewall Request Count.

Congrats! You've successfully gone through the steps of deploying, securing, scaling, and testing a Static Web App.