Compliance

Harden Azure App Service apps

One capability across web apps and API apps: make sure every app forces HTTPS, refuses remote debugging, scopes CORS to the origins you actually own, and runs a supported language runtime, instead of shipping the permissive defaults to the internet.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-api-app-client-certificates azure-api-app-cors-restricted azure-api-app-java-latest azure-api-app-php-latest azure-api-app-python-latest azure-api-app-remote-debugging-off azure-web-app-client-certificates azure-web-app-cors-restricted azure-web-app-remote-debugging-off

Hardening App Service apps: the basics

What does an under-hardened Azure App Service app actually look like?

An App Service app is an internet-facing front door, and its exposure shows up as a handful of distinct settings rather than one switch. HTTPS-only can be off, so the app still answers plain HTTP and any session cookie or token travels in the clear. CORS can be set to a wildcard '*', so any website in the world can call the app's API from a victim's browser. Remote debugging can be left enabled, so a debugger port stays open on a production app long after the one engineer who needed it has moved on. The language runtime, Java, PHP or Python, can be pinned to a version that has stopped receiving security patches. Each is its own Microsoft Defender for Cloud recommendation, but the underlying risk is the same: an app that accepts, trusts or runs more than you meant it to.

Defender for Cloud turns each of these into its own recommendation, which is why one App Service plan with a few apps on it can fail several checks at once. 'App Service apps should only be accessible over HTTPS', 'Remote debugging should be turned off' and the CORS recommendation are the ones that close the widest doors, and they pair with the client-certificate and runtime-version checks to form a single capability. They read as separate problems on the report, but they are one job: stop shipping the permissive defaults and pin the app to a hardened, supported configuration.

Most of this is drift, not intent. An app scaffolded with a wildcard CORS rule for local testing that never got tightened, a deployment slot where someone flipped remote debugging on to chase a bug, a runtime that was current when the app shipped and quietly aged out of support. The work is to find every app that forces HTTPS too loosely, trusts too many origins, leaves a debugger open or runs an unsupported runtime, decide which few settings are deliberate, and pin the rest to a hardened baseline.

In this lesson you will learn how Azure App Service expresses transport security, cross-origin trust, debugging exposure and runtime support, how to find every under-hardened app in a subscription, and how to pin them to a safe baseline without breaking the apps that have a legitimate reason for a given setting. The Controls this lesson covers section lists every Defender for Cloud recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The wildcard that opened the door

A CORS policy set to '' is one of the most common findings on any App Service estate, and it is almost never a deliberate decision. It is the value a developer pastes in to make a browser error go away during local testing, and then it ships. The catch is that a wildcard origin tells every website on the internet that it may call your API from a logged-in user's browser, which is exactly the trust boundary CORS exists to defend. Azure does not set a wildcard for you, so every '' in the estate was typed by someone, usually to unblock a demo, and then forgotten.

Finding under-hardened apps across a subscription

Sam is the security lead at a scale-up preparing for its first ISO 27001 audit. Defender for Cloud shows App Service findings spread across a dozen apps in two subscriptions that pre-date the team's current guardrails.

Rather than work the findings one by one, Sam starts by listing which apps still allow plain HTTP and which still leave remote debugging on, so the genuinely exposed front doors can be separated from drift before anything changes.

Start by listing the apps that do not force HTTPS and that still have a debugger port open. These are the widest-open doors.

$ az webapp list --query "[?!httpsOnly].{name:name, group:resourceGroup}" -o table

Name Group

---------------- ------------------

public-api-prod rg-app-prod

internal-admin rg-app-internal

# public-api-prod answers plain HTTP AND is internet-facing. Force HTTPS first.

An internet-facing app that still answers plain HTTP is the highest-value target in this group. Fix these first, then check each one for an open debugger port and a wildcard CORS rule.

How Defender for Cloud decides an App Service app is under-hardeneddeep dive

Most App Service recommendations resolve to one of a few properties on the site or its configuration. 'httpsOnly' on the site: when it is false, the app answers plain HTTP, so cookies and tokens can travel unencrypted. The CORS allowed-origins list in 'siteConfig.cors': when it contains a single '*', any origin may call the app from a browser, which defeats the cross-origin trust boundary. 'siteConfig.remoteDebuggingEnabled': when it is true, a debugger port is reachable on the app, widening its attack surface even though access is authenticated. The runtime stack, exposed as 'siteConfig.linuxFxVersion' on Linux, pins the app to a Java, PHP or Python version that may have aged out of security support.

Several of these checks have a history worth knowing. The classic 'API App' resource type has been retired, so the API-app-specific variants ('CORS should not allow every resource to access API Apps', 'Remote debugging should be turned off for API App', the API-app client-certificate check and the Java, PHP and Python API-app version checks) are deprecated and folded into the consolidated 'App Service apps...' recommendations and policies. The language-version policies were also removed from the Microsoft Cloud Security Benchmark default initiative: they still work and can be assigned, but they no longer auto-assign, so a clean MCSB score does not by itself prove your runtimes are supported. Author for the consolidated, current recommendations and treat the runtime check as something you assign deliberately.

Defender for Cloud evaluates these against the Microsoft Cloud Security Benchmark on a periodic cycle, so a fix does not flip the recommendation to Healthy instantly. The control-plane change itself is immediate, but the posture catches up on the next assessment. The strongest position combines the per-app setting with an Azure Policy backstop: a deny on non-HTTPS apps and an audit on runtime versions means the hardened configuration is enforced, not merely encouraged.

What is the impact of leaving App Service under-hardened?

The direct impact is application-layer compromise. An app that answers plain HTTP leaks every session cookie and bearer token to anyone who can observe the traffic, and a stolen session is a logged-in user until it expires. A wildcard CORS policy lets a malicious site call your authenticated API from a victim's browser, turning their session into the attacker's. An open remote-debugging port is extra authenticated attack surface on a production app that almost nobody is using deliberately. An end-of-life runtime ships known, unpatched vulnerabilities straight to the internet. None of these requires a sophisticated attacker; they are the settings automated scanners look for first.

The second-order impact is blast radius. Every plain-HTTP endpoint, wildcard origin, open debugger and stale runtime is attack surface that has to be defended continuously. Pinning every app to a hardened baseline shrinks that surface to a known, supported configuration you can monitor, put a web application firewall in front of, and reason about.

On the compliance side, every modern framework, ISO 27001, SOC 2, HIPAA, PCI DSS and the UK and EU data-protection regimes, expects evidence that data in transit is encrypted, that cross-origin trust is scoped, and that internet-facing software runs supported versions. A passing set of App Service recommendations across every subscription is one of the cheapest and most defensible artefacts you can hand an auditor.

How do you harden App Service apps safely?

Work the capability as one loop rather than chasing individual findings. The order matters: identify the apps with live external callers before you change CORS or force HTTPS, so you do not break a partner integration or a redirect.

1. Inventory every app by exposure

List the apps that are not HTTPS-only, that have a wildcard CORS origin, that leave remote debugging on, and whose runtime has aged out of support. Treat this inventory as the source of truth, not the Defender finding count, because one app can trigger several recommendations at once.

2. Separate deliberate settings from drift

Most findings are unintended. For each app, decide whether a setting is on purpose. A public API may genuinely need a small, named set of CORS origins, never a wildcard. An app may need a client certificate for mutual TLS; that works fine over HTTP/2 in Required or Optional mode, but avoid the Optional Interactive User mode and certificate exclusion paths on an HTTP/2 or TLS 1.3 app, because those settings rely on TLS renegotiation, which HTTP/2 and TLS 1.3 do not support. Everything else, the stray wildcard, the forgotten debugger, the plain-HTTP default, is drift and can be closed.

3. Pin the baseline, highest impact first

Force HTTPS-only, turn off remote debugging, replace the wildcard CORS rule with the explicit origins you own, and move each app to a supported runtime. Prioritise internet-facing apps over internal ones. Most changes are a single command per app and take effect immediately; runtime upgrades need a test pass first.

4. Ratchet it shut with Azure Policy

Assign a deny policy so no new app can be created without HTTPS-only, audit for wildcard CORS and for unsupported runtimes, so the hardened configuration is enforced rather than merely encouraged. Look the built-in policies up by display name rather than pasting a GUID, so the assignment always targets the current definition.

SUB="/subscriptions/00000000-0000-0000-0000-000000000000"
RG="rg-app-prod"

# Harden every app that is not already HTTPS-only.
for app in $(az webapp list -g "$RG" \
    --query "[?!httpsOnly].name" -o tsv); do
  # 1. Force HTTPS on the site itself.
  az webapp update -g "$RG" -n "$app" --https-only true
  # 2. Turn off the remote debugger.
  az webapp config set -g "$RG" -n "$app" --remote-debugging-enabled false
  # 3. Drop any wildcard CORS origin (replace with your own origins after).
  az webapp cors remove -g "$RG" -n "$app" --allowed-origins '*'
  echo "$app: HTTPS forced, remote debugging off, wildcard CORS removed"
done

# Ratchet it shut: deny any future app that is not HTTPS-only.
# Look the built-in policy up by display name, never hardcode the GUID.
pid=$(az policy definition list \
  --query "[?displayName=='App Service apps should only be accessible over HTTPS'].name" -o tsv)
az policy assignment create \
  --name deny-appservice-http \
  --policy "$pid" \
  --scope "$SUB"

Quick quiz

Question 1 of 5

Defender for Cloud shows App Service findings across HTTPS-only, CORS, remote debugging and runtime versions on several apps. What is the most efficient way to think about them?

Keep learning

Go deeper on how Azure App Service expresses transport security, cross-origin trust, debugging and runtime support across the settings in this capability.

You can now treat Azure App Service as one capability rather than a scatter of findings: inventory what answers plain HTTP, trusts every origin, leaves a debugger open or runs an unsupported runtime, separate the deliberate settings, pin the rest to a hardened baseline highest-impact first, and ratchet the estate shut with Azure Policy. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Hardening App Service apps: the cost and risk view

A near-zero-cost capability that removes a broad class of application-layer breach liability

App Service hardening is almost entirely a configuration capability, and configuration costs nothing in Azure spend to fix. Forcing HTTPS, turning off remote debugging, scoping CORS to your own origins and requiring a client certificate do not change your bill; they change settings. The only real cost sits in the exceptions: a runtime upgrade that needs developer time to test, or a public API that has to coordinate a CORS change with its callers so it does not break a partner integration.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. An internet-facing API that trusts every origin and answers plain HTTP carries a far higher expected loss than an internal admin app behind a private endpoint, yet both surface as a single red finding. Map the failures to what each app actually serves, and prioritise by exposure, not by recommendation count.

The arithmetic is one-sided. The remediation is mostly engineering time plus a bounded amount of testing for the runtime upgrades and the CORS changes that touch live callers. The downside of leaving it is the documented cost of an application-layer breach: a stolen session over plain HTTP, data exfiltrated through an over-permissive CORS policy, or an exploit against an end-of-life runtime, with the fines, notification and forensics that follow.

This lesson is for the finance partner who sees a cluster of App Service findings on the security report and wants to know what the right response is and what it costs. It covers why most of these controls are free to fix, which exceptions, the runtime upgrades and the partner-facing CORS changes, carry a real cost in engineering time, and how to turn a list of red findings into a risk-ordered remediation plan.

Fun fact

The wildcard that opened the door

How a finance partner frames the App Service decision

Sam is the finance partner supporting the platform team's ISO 27001 push. The security report lands with fourteen App Service findings spread across a dozen apps in two older subscriptions. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding. Forcing HTTPS, turning off remote debugging or scoping CORS changes nothing on the Azure bill, so the spend question is narrow: only the apps whose runtime has to be upgraded carry real developer time to test, and only the public API whose CORS rule touches live partner callers needs a coordinated change so it does not break an integration.

Sam asks the team to map each failing app to what it actually serves. Two are internet-facing APIs that trust every origin and answer plain HTTP, one is an internal admin tool behind a private endpoint that simply never had HTTPS-only set, and three run a PHP version that has reached end of life. The list is reframed on the risk register: the two public APIs are high expected-loss items to harden today at zero Azure cost, the runtime upgrades are bounded engineering tasks to schedule with test time, and the internal app is low-value drift to sweep up. The finance pack reads: 'Most findings close at no incremental spend; three runtime upgrades and one partner-facing CORS change need scheduled engineering time; the only thing standing between us and a clean posture is testing effort, not budget.'

Why App Service hardening belongs on the risk register

The cost model here is asymmetric in a way that is common for configuration security. Hardening costs nothing in Azure spend for the great majority of apps, and leaving the defaults on creates an open-ended tail risk. Each failing recommendation is an app where a future incident could ride a stolen session, a cross-origin call or an unpatched runtime, and while the probability per app is low, the probability across the whole estate over years is not.

The documented cost of an application-layer breach includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and customer churn. Against that, the remediation is mostly engineering time plus a bounded amount of testing for the runtime upgrades and the partner-facing CORS changes. The finance role is to attach expected loss to each failing app, so the work is prioritised by risk, not by the order the report lists it.

What finance can do about the App Service gap

Finance cannot tighten an app setting, but it owns the framing that turns a scatter of red findings into a risk-ordered plan with almost no incremental Azure spend and a clearly bounded set of exceptions. Three levers.

1. Separate the zero-cost closures from the bounded exceptions

Make explicit that the overwhelming majority of App Service findings cost nothing in Azure spend to fix: forcing HTTPS, turning off remote debugging or removing a wildcard CORS rule does not move the bill. The only real cost sits in the runtime upgrades that need developer test time and the partner-facing CORS changes that have to be coordinated with live callers. Budget those as discrete lines and treat everything else as engineering time, so nobody can claim the whole capability is a spending decision.

2. Order the work by expected loss, not by finding count

An internet-facing API that trusts every origin and answers plain HTTP, and an internal admin app behind a private endpoint that simply never had HTTPS-only set, both show up as a single red finding, but their expected loss differs by orders of magnitude. Ask the team to map each failing app to what it serves and prioritise the internet-facing ones. The metric that belongs on the cost-and-security review is the count of App Service findings weighted by each app's exposure, not the raw total.

3. Require documented exceptions for deliberate settings

Any app that keeps a specific CORS origin, or that requires a client certificate for mutual TLS, should carry a recorded, finance-visible reason. The distinction between 'we scoped this API to two named partner origins on purpose' and 'this still has a wildcard nobody noticed' is exactly what makes the posture defensible at audit and in the aftermath of any incident.

Quick quiz

Question 1 of 5

A security report shows fourteen App Service findings. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how Azure App Service expresses transport security, cross-origin trust, debugging and runtime support across the settings in this capability.

You have finished the finance view of hardening App Service. You know the cost model is one-sided: closing the great majority of findings is free in Azure spend, only the runtime upgrades and partner-facing CORS changes carry a bounded engineering cost, and the downside of leaving the defaults on is the documented and unbounded cost of an application-layer breach. Next time a cluster of App Service findings lands, you will order them by exposure, ring-fence the real exceptions, and ask for them on the record rather than asking how much remediation will cost.

Back to the library

Hardening App Service apps: the headline

Whether the apps you expose to the internet ship hardened by default or with the permissive defaults still on

App Service is where your code meets the public internet, and the report shows this as a scatter of separate findings: this app still answers plain HTTP, that one trusts every origin, another has a debugger port open, a fourth runs a runtime that stopped getting security fixes a year ago. Any one of them is a configuration mistake away from an application-layer breach.

The leadership question is not 'are we compliant today?' It is 'when the next app ships tomorrow, does it ship hardened by default?' The defensible end state is that HTTPS-only and a supported runtime are enforced by policy, remote debugging is off everywhere, and CORS is scoped to the origins you actually own, with any deliberate exception documented.

None of this is a cost decision. Hardening App Service is essentially free in Azure terms. It is a governance decision about whether your public apps are secure by design or only by every developer remembering to change four settings before they go live.

A short read for the leader who needs to know what an under-hardened web app reveals, why pinning it to a safe baseline is a governance decision rather than a budget one, and what a defensible end state looks like across the estate.

Fun fact

The wildcard that opened the door

What it looks like when App Service ships hardened by design, not by habit

After a peer company disclosed that an attacker had ridden a stolen session token out of a web app that still accepted plain HTTP, the CEO asked the obvious question at the next review: could that happen to us? The honest answer at the time was that it depended on whether each team had remembered to flip HTTPS-only on, because transport security across the estate was governed by habit rather than policy.

The team's response was to stop treating App Service as a per-app cleanup and start treating it as a guardrail. They listed every app that answered plain HTTP, trusted every origin, left a debugger open or ran an unsupported runtime, hardened each one, then set Azure Policy to deny the creation of any new app that is not HTTPS-only and to audit for a supported runtime. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no, the platform forces HTTPS by design, debugging is off, CORS is scoped, and any exception is documented.' That shift, from relying on every developer remembering four settings to making the insecure state structurally hard, is the one-line confidence signal this capability delivers, and it costs nothing in Azure spend to reach.

Why this is a board-level risk

Many application-layer breaches trace back to the same root causes: an app that accepted plain HTTP, trusted every origin, or ran software that stopped getting security fixes. Hardening App Service is the capability that makes those root causes structurally difficult, and an Azure Policy backstop makes the worst of them close to impossible to reintroduce.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially engineering time. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.

The leadership move on App Service

The executive handle is not to approve each fix individually; it is to require that App Service apps ship hardened by policy and that the small number of deliberate settings are documented, on the record.

1. Set a deadline to reach a backstopped end state

Ask for a date by which the estate is inventoried, every app forces HTTPS, remote debugging is off, CORS is scoped to owned origins, runtimes are supported, and Azure Policy denies the creation of any new app that is not HTTPS-only. A backstop that no individual app can override is the difference between checking nothing is exposed today and guaranteeing the insecure state cannot ship tomorrow.

2. Ask for proof, not assurance

The proof that this is closed is not a verbal 'we are on it.' It is a passing set of App Service recommendations across every subscription plus evidence that the deny and audit policies are assigned. Because Defender for Cloud assesses on a periodic cycle, and because the runtime-version policy no longer auto-assigns under the benchmark, ask for that evidence with lead time before any audit deadline.

3. Treat deliberate settings as named, owned exceptions

A small number of apps will keep a specific CORS origin or require a client certificate, and that is fine. The leadership requirement is that each is a deliberate, documented decision with an owner, not a default left on. The goal is not zero configured settings; it is zero unintended ones.

Quick quiz

Question 1 of 5

At a board review you ask whether a stolen-session incident like a competitor's could happen to your estate. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure App Service expresses transport security, cross-origin trust, debugging and runtime support across the settings in this capability.

Two takeaways. App Service hardening is the rare control where the risk of inaction is severe and the cost of action is essentially engineering time, so it is the trade you should be quickest to approve. And the defensible end state is not 'we checked and nothing is exposed today'; it is Azure Policy that enforces HTTPS-only and a supported runtime and keeps remote debugging off, making insecure apps structurally hard to ship, with the few deliberate settings documented and owned.

Back to the library

Controls this lesson covers

One capability, many Microsoft Defender for Cloud recommendations. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

Azure App Service

Part of the learning path Harden Azure workloads

Harden Azure App Service apps

Hardening App Service apps: the basics

The wildcard that opened the door

Finding under-hardened apps across a subscription

How Defender for Cloud decides an App Service app is under-hardeneddeep dive

What is the impact of leaving App Service under-hardened?

How do you harden App Service apps safely?

1. Inventory every app by exposure

2. Separate deliberate settings from drift

3. Pin the baseline, highest impact first

4. Ratchet it shut with Azure Policy

Quick quiz

Keep learning

Hardening App Service apps: the cost and risk view

The wildcard that opened the door

How a finance partner frames the App Service decision

Why App Service hardening belongs on the risk register

What finance can do about the App Service gap

1. Separate the zero-cost closures from the bounded exceptions

2. Order the work by expected loss, not by finding count

3. Require documented exceptions for deliberate settings

Quick quiz

Keep learning

Hardening App Service apps: the headline

The wildcard that opened the door

What it looks like when App Service ships hardened by design, not by habit

Why this is a board-level risk

The leadership move on App Service

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Treat deliberate settings as named, owned exceptions

Quick quiz

Keep learning

Controls this lesson covers

Azure App Service

Related compliance lessons