Compliance

Harden Azure Function apps

One capability across every Function app: make sure the HTTP surface it exposes is not reachable by anyone the internet, that nobody can attach a debugger or call an admin endpoint, and that every endpoint behind it is authenticated, used and deliberate.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-function-app-api-endpoints-authenticated azure-function-app-client-certificates azure-function-app-cors-restricted azure-function-app-remote-debugging-off azure-function-app-unused-api-endpoints-removed

Hardening Function apps: the basics

What does an exposed Azure Function app actually look like?

A Function app is a small, internet-facing web server that runs your code on an HTTP trigger, and its exposure shows up in a handful of distinct shapes rather than one setting. CORS can be left as a wildcard so any website in the world can call the app from a browser. Remote debugging can be left on so a debugger can attach to the running process. Incoming client certificates can be off so the app cannot insist a caller present one. Authentication can be absent so an HTTP-triggered endpoint answers anonymous requests. And old endpoints that nobody calls any more can sit live, unpatched and forgotten. Each is its own Defender for Cloud recommendation, but the underlying risk is the same: an HTTP surface that more of the internet can reach, call or attach to than you meant.

Microsoft Defender for Cloud turns each of these into its own recommendation, which is why one Functions-heavy subscription can fail several Function app checks at once. 'CORS should not allow every resource to access Function Apps', 'Remote debugging should be turned off for Function App', and 'Authentication should be enabled on API endpoints hosted in Function Apps' close the widest doors, and they pair with the client-certificate and unused-endpoint recommendations to form a single capability. They read as separate problems on the report, but they are one job: shrink the HTTP surface to exactly the callers, endpoints and access paths you actually intend.

Most of this exposure is drift, not intent. A wildcard CORS rule that a developer set to unblock a frontend during testing and never tightened, remote debugging left on after a live troubleshooting session, an app deployed before Easy Auth was the default, an endpoint kept past the feature that needed it. The work is to find every Function app whose HTTP surface is wider than intended, decide which callers and endpoints are legitimate, and lock the rest down.

In this lesson you will learn how an Azure Function app expresses its HTTP attack surface, how to find every over-exposed app in a subscription, and how to lock them down without breaking the callers and endpoints that are legitimate. 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 function nobody was calling

Serverless functions are easy to stand up and just as easy to forget, which is why 'shadow' and abandoned endpoints are now a named category in API security. An HTTP-triggered function written for a campaign that ended, or a test endpoint that shipped to production, keeps answering requests long after anyone remembers it exists, and it stops receiving the attention that keeps the rest of the codebase patched. Defender for Cloud now catalogues the API endpoints inside your Function apps and flags the ones that have seen no traffic, precisely because the endpoint you forgot is the one an attacker is most likely to find first.

Finding Function app exposure across a subscription

Priya is the security lead at a scale-up preparing for its first SOC 2 audit. Defender for Cloud shows Function app 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, Priya starts by listing which apps still allow any origin via CORS and which still have remote debugging switched on, so the genuinely public APIs can be separated from drift before anything changes.

Start by listing the apps whose CORS allows every origin and whether remote debugging is still on. These are the widest-open doors.

$ az functionapp list --query "[].name" -o tsv | while read app; do rg=$(az functionapp show -n "$app" --query resourceGroup -o tsv); cors=$(az functionapp cors show -n "$app" -g "$rg" --query "allowedOrigins" -o tsv); dbg=$(az functionapp config show -n "$app" -g "$rg" --query "remoteDebuggingEnabled" -o tsv); echo "$app $cors $dbg"; done

Name CORS RemoteDebug

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

ordersapiprod * True

internaljobs https://app.contoso.com False

# ordersapiprod allows every origin AND has a debugger pathway open. Close it first.

An app whose CORS is a wildcard and that still has remote debugging on is the highest-value target in this group. Fix these first.

How Defender for Cloud decides a Function app is exposeddeep dive

Most Function app recommendations resolve to one of a few properties on the site or its config. CORS lives at 'properties.cors.allowedOrigins' on the app's web config: when it contains a single '*' entry, any website can call the app from a browser, which is what the CORS recommendation flags. Remote debugging is 'remoteDebuggingEnabled' on the same config: when it is true, a debugger can attach to the running process, and Azure turns it off automatically after 48 hours precisely because it should never be a steady state. Incoming client certificates are 'clientCertEnabled' on the site: when false, the app cannot require a caller to present a certificate.

Authentication is different in kind. The 'Function apps should have authentication enabled' recommendation checks whether App Service Authentication, often called Easy Auth, is switched on, expressed as 'siteAuthEnabled'. Easy Auth is a middleware layer that runs in front of your code and validates a token before any request reaches a function, so when it is off, every HTTP-triggered endpoint relies on whatever your own code does, or does not, check. The unused-endpoint and per-endpoint authentication recommendations come from Defender for APIs, which catalogues the actual HTTP routes inside each app from observed traffic, then flags endpoints that have seen no calls for 30 days and endpoints reachable without authentication. These are preview, traffic-based recommendations rather than a single config flag, so they need the Defender for APIs plan and a window of observed traffic to populate.

Defender for Cloud evaluates the config-based checks 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, and the traffic-based API recommendations catch up only after enough observed traffic. This matters when you are gathering audit evidence against a deadline.

What is the impact of leaving a Function app exposed?

The direct impact is unauthorised use of your code. An HTTP-triggered function with no authentication answers anyone who finds its URL, and internet-facing endpoints are found quickly by automated scanners. A wildcard CORS rule lets any website call the app from a victim's browser, carrying that user's context. Remote debugging left on is a pathway to attach to the process running your code. Each of these turns a function from a private utility into a callable, abusable surface, and abuse is not only data leakage: a function that triggers downstream work can run up real spend when it is called at scale by someone who is not you.

The second-order impact is blast radius. Every unauthenticated endpoint and over-permissive CORS rule is attack surface that has to be defended continuously, and a forgotten endpoint is the worst case because nobody is watching it or patching it. Locking Function apps down shrinks that surface to the endpoints you actually operate, behind authentication you control, which are the ones you can monitor, rate-limit 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 application endpoints authenticate their callers and that the attack surface is minimised. A passing set of Function app recommendations across every subscription is a cheap and defensible artefact to hand an auditor.

How do you lock Function apps down safely?

Work the capability as one loop rather than chasing individual findings. The order matters: identify the legitimate callers and endpoints before you start closing things, so you do not break a live integration.

1. Inventory every app by exposure

List the apps whose CORS allows every origin, that still have remote debugging on, that do not require a client certificate, and that have authentication switched off. Treat this inventory as the source of truth, not the Defender finding count, because one app can trigger several recommendations at once.

2. Separate legitimate callers and endpoints from drift

Most exposure is unintended. For each app, decide which origins genuinely need cross-origin access and which endpoints are still in use. A wildcard CORS rule replaced by the two domains that actually call the app, and an endpoint inventory checked against Defender for APIs traffic, turns 'open to everything' into 'open to exactly what we run'. Everything else is drift and can be closed.

3. Close the doors, highest impact first

Replace wildcard CORS with the explicit list of origins, turn remote debugging off, set a minimum TLS version of 1.2, enable incoming client certificates where the app expects them, and put App Service Authentication in front of any HTTP-triggered app that should not be anonymous. Remove the endpoints Defender for APIs reports as unused. Prioritise apps that handle data over internal utilities. Each change takes effect immediately on the control plane.

4. Ratchet it shut with Azure Policy

Assign the built-in policies that audit Function apps without authentication, with a CORS wildcard, with remote debugging on, or without client certificates, so any new app that ships in the open state is flagged rather than discovered later. These policies are audit-only, so they surface drift without blocking deployments, which is the right posture for a setting that has legitimate exceptions.

# Close the highest-impact Function app exposure first: wildcard CORS, remote
# debugging, weak TLS, and missing client certificates, app by app.
RG=my-rg
APP=ordersapiprod

# 1. Replace wildcard CORS with the origins that actually call the app.
az functionapp cors remove -g "$RG" -n "$APP" --allowed-origins "*"
az functionapp cors add    -g "$RG" -n "$APP" \
  --allowed-origins https://app.contoso.com https://admin.contoso.com

# 2. Turn off remote debugging and require modern TLS.
az functionapp config set -g "$RG" -n "$APP" \
  --remote-debugging-enabled false \
  --min-tls-version 1.2

# 3. Require incoming client certificates where the app expects them.
az functionapp update -g "$RG" -n "$APP" \
  --set clientCertEnabled=true --set clientCertMode=Required

# 4. Put App Service Authentication (Easy Auth) in front of an HTTP-triggered app
#    so anonymous callers are rejected before they reach your code.
az webapp auth update -g "$RG" -n "$APP" \
  --enabled true \
  --action LoginWithAzureActiveDirectory \
  --aad-client-id "$CLIENT_ID" \
  --aad-token-issuer-url "https://sts.windows.net/$TENANT_ID/"

# 5. Ratchet it shut: audit any future app that ships without authentication.
#    Look the built-in policy up by its exact display name, never hardcode the GUID.
pid=$(az policy definition list \
  --query "[?displayName=='Function apps should have authentication enabled'].name" -o tsv)
az policy assignment create \
  --name audit-funcapp-auth \
  --policy "$pid" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"

Quick quiz

Question 1 of 5

Defender for Cloud shows Function app findings across CORS, remote debugging, client certificates and authentication on several apps. What is the most efficient way to think about them?

Keep learning

Go deeper on how an Azure Function app expresses its HTTP attack surface across the settings in this capability.

You can now treat Azure Function apps as one capability rather than a scatter of findings: inventory which apps are callable, debuggable or anonymous more widely than intended, separate the legitimate callers and endpoints, close the rest highest-impact first, and ratchet the estate shut with Azure Policy audit rules. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Hardening Function apps: the cost and risk view

A near-zero-cost capability that removes a whole class of unauthenticated-API liability

Function app exposure is a common source of unauthenticated API access in Azure, and almost every control in this group costs nothing in Azure spend to fix. Tightening CORS, turning off remote debugging, requiring a client certificate or removing a dead endpoint does not change your bill. The cost sits entirely in the few exceptions: the apps that need an identity provider wired up for Easy Auth, which is configuration time rather than spend, and the unused-endpoint detection, which surfaces through Defender for APIs and so depends on having that plan enabled.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A Function app that serves an unauthenticated endpoint returning customer data carries a far higher expected loss than an internal app behind a private network, yet both can surface as a single red finding. Map the failures to what each app actually does and prioritise by exposure, not by recommendation count.

The arithmetic is one-sided. The remediation is engineering time plus a bounded amount of identity configuration for the apps that need authentication. The downside of leaving it is the documented cost of an exposed or abused API: data leakage, fraudulent use of a function that triggers downstream spend, breach notification, forensics and reputational damage.

This lesson is for the finance partner who sees a cluster of Function app 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 carry a real cost, and how to turn a list of red findings into a risk-ordered remediation plan.

Fun fact

The function nobody was calling

How a finance partner frames the Function app decision

Priya is the finance partner supporting the platform team's SOC 2 push. The security report lands with eleven Function app 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. Tightening CORS, turning off remote debugging or requiring a client certificate changes nothing on the Azure bill, so the spend question is narrow: only the apps that need an identity provider wired up for authentication carry real work, and even that is configuration time rather than incremental Azure spend, with the unused-endpoint detection depending on whether the Defender for APIs plan is already on.

Priya asks the team to map each failing app to what it actually does. Two apps expose unauthenticated endpoints that return customer data, one is an internal jobs runner that is already behind a private network, and the rest are wildcard-CORS and remote-debugging drift on apps nobody tightened after testing. The list is reframed on the risk register: the two unauthenticated customer-data APIs are high expected-loss items to close today at zero Azure cost, the internal runner is low risk to sweep up, and the drift is a quick batch of config changes. The finance pack reads: 'Nine findings close at no incremental spend; two need an identity provider configured, which is engineering time not budget; the only thing standing between us and a clean posture is work, not money.'

Why Function app exposure belongs on the risk register

The cost model here is asymmetric in a way that is common for security work but easy to forget. Locking Function apps down costs nothing in Azure spend for the great majority of apps, and leaving them open creates an unbounded tail risk. Each failing recommendation is an app where a future caller could read data they should not, or abuse a function in a way that drives downstream spend, and while the probability per app is low, the probability across all apps over years is not.

The documented cost of an exposed-API incident includes mandatory breach notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, fraudulent compute and downstream charges from abused functions, and customer churn. Against that, the remediation is engineering time plus a bounded amount of identity configuration for the apps that need authentication. 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 Function app 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 configuration work

Make explicit that the overwhelming majority of Function app findings cost nothing in Azure spend to fix: tightening CORS, turning off remote debugging, requiring a client certificate or removing a dead endpoint does not move the bill. The only real work sits in the apps that need an identity provider wired up for authentication, and even that is engineering time rather than spend, with the unused-endpoint detection depending on whether the Defender for APIs plan is already enabled. 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 app exposing an unauthenticated endpoint that returns customer data and an internal utility behind a private network both show up as a single red finding, but their expected loss differs by orders of magnitude. Ask the team to map each failing recommendation to what the app actually does and prioritise the data-handling, internet-facing apps first. The metric that belongs on the cost-and-security review is the count of Function app findings weighted by what each app exposes, not the raw total.

3. Require documented exceptions for genuinely open surfaces

Any app left callable from many origins on purpose, or any anonymous endpoint that has to stay anonymous such as a public webhook receiver, should carry a recorded, finance-visible reason and the compensating control around it, such as a shared-secret check or rate limiting. The distinction between 'we reviewed this and left it open deliberately' and 'we never noticed it was open' 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 eleven Function app findings. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how an Azure Function app expresses its HTTP attack surface across the settings in this capability.

You have finished the finance view of hardening Function apps. You know the cost model is one-sided: closing the great majority of findings is free in Azure spend, only the apps that need an identity provider configured carry real work, and that is engineering time, while the downside of leaving exposure open is the documented and unbounded cost of an abused or scraped API. Next time a cluster of Function app findings lands, you will order them by expected loss, 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 Function apps: the headline

Whether any piece of code you run can be called, or tampered with, by people you did not intend

A Function app is code you run on demand behind an internet-facing endpoint. If that endpoint answers anonymous callers, accepts requests from any website, or still has a debugger pathway open, then a single mistake turns it into an entry point. The report shows this as a scatter of separate findings across the estate.

The leadership question is not 'are we compliant today?' It is 'if someone finds one of our function endpoints tomorrow, can they call it, abuse it, or attach to it?' The defensible end state is that every HTTP-triggered app authenticates its callers, restricts which sites can call it, has no debugging pathway open, and runs no endpoint that nobody uses.

None of this is a cost decision. Hardening Function apps is essentially free in Azure terms. It is a governance decision about whether the HTTP surface of your code is locked to what you intend, or left open to whatever the last deployment happened to allow.

A short read for the leader who needs to know what an exposed Function app reveals, why locking it down is a governance decision rather than a budget one, and what a defensible end state looks like across the estate.

Fun fact

The function nobody was calling

What it looks like when Function app exposure is prevented by design, not luck

After news that a competitor had a serverless endpoint scraped for customer records because it never required a login, 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 put authentication in front of every function, because that was governed by habit rather than policy.

The team's response was to stop treating Function apps as a per-app cleanup and start treating them as a guardrail. They listed every app with wildcard CORS, remote debugging on, or no authentication, put Easy Auth in front of the HTTP-triggered apps that needed it, removed the endpoints nobody was calling, locked the debugging pathway shut, and then set Azure Policy to audit any new Function app that ships without authentication or with a CORS wildcard. The next time the CEO asked the question, the answer had changed from 'we believe so' to 'no, every function endpoint authenticates its callers, and the policy flags any that does not.' That shift, from relying on everyone remembering to add a login to making its absence visible and rare, 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

A growing share of breaches now start at an API endpoint rather than a stolen password, and a Function app that answers anonymous callers is exactly that kind of endpoint. Putting authentication in front of every function, restricting who can call it, and removing the endpoints nobody uses is the capability that makes that class of attack structurally harder, and an Azure Policy that audits new apps keeps it from creeping back.

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 Function apps

The executive handle is not to approve each closure individually; it is to require that every HTTP-triggered app authenticates its callers and that the small number of deliberately open surfaces 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 HTTP-triggered app that should not be anonymous has authentication in front of it, wildcard CORS and remote debugging are gone, unused endpoints are removed, and Azure Policy audits any new app that ships without authentication or with a CORS wildcard. A policy that surfaces drift the moment it appears is the difference between checking nothing is exposed today and knowing the moment something becomes exposed 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 Function app recommendations across every subscription plus evidence that the audit policies are assigned. Because Defender for Cloud assesses on a periodic cycle, and the API recommendations need observed traffic, ask for that evidence with a little lead time before any audit deadline rather than the morning of.

3. Treat the genuinely open endpoints as named, owned exceptions

A small number of endpoints are open on purpose, such as a public webhook receiver that authenticates by a shared secret in the payload rather than a login. That is fine. The leadership requirement is that each is a deliberate, documented decision with an owner and a compensating control, not an accident left anonymous. The goal is not zero open endpoints; it is zero unintended ones.

Quick quiz

Question 1 of 5

At a board review you ask whether a scraped-serverless-API 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 an Azure Function app expresses its HTTP attack surface across the settings in this capability.

Two takeaways. Function app exposure 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 anonymous today'; it is that every HTTP-triggered app authenticates its callers, the debugging and wildcard-CORS pathways are gone, and Azure Policy audits any new app that ships without authentication, with the few deliberately open endpoints 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 Functions

Part of the learning path Harden Azure workloads

Harden Azure Function apps

Hardening Function apps: the basics

The function nobody was calling

Finding Function app exposure across a subscription

How Defender for Cloud decides a Function app is exposeddeep dive

What is the impact of leaving a Function app exposed?

How do you lock Function apps down safely?

1. Inventory every app by exposure

2. Separate legitimate callers and endpoints from drift

3. Close the doors, highest impact first

4. Ratchet it shut with Azure Policy

Quick quiz

Keep learning

Hardening Function apps: the cost and risk view

The function nobody was calling

How a finance partner frames the Function app decision

Why Function app exposure belongs on the risk register

What finance can do about the Function app gap

1. Separate the zero-cost closures from the configuration work

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

3. Require documented exceptions for genuinely open surfaces

Quick quiz

Keep learning

Hardening Function apps: the headline

The function nobody was calling

What it looks like when Function app exposure is prevented by design, not luck

Why this is a board-level risk

The leadership move on Function apps

1. Set a deadline to reach a backstopped end state

2. Ask for proof, not assurance

3. Treat the genuinely open endpoints as named, owned exceptions

Quick quiz

Keep learning

Controls this lesson covers

Azure Functions

Related compliance lessons