Azure Functions 1.0.23001

Last reviewed Sep 6, 2026

Export as PDF

Prompt Details

Prompt Composition

1prompt
  1. Azure Functions 1.0.23001103 lines · 3.4K tokens

CWE Coverage

  • 20
  • 78
  • 89
  • 94
  • 250
  • 287
  • 294
  • 295
  • 306
  • 319
  • 345
  • 362
  • 470
  • 502
  • 532
  • 598
  • 732
  • 770
  • 807
  • 829
  • 862
  • 863
  • 918
  • 922
  • 942
  • 1395

Prompt Preview

Use these rules only for Azure Functions runtime 1.x at host release 1.0.23001. This legacy C# line uses the in-process .NET Framework model; support ended on 2026-09-14. Apply compatible C# and .NET Framework security guidance alongside these rules.

Support boundary and migration

  • Keep FUNCTIONS_EXTENSION_VERSION=~1 only for an existing app that cannot yet leave .NET Framework; do not start a new workload on runtime 1.x.
  • Run only a C# in-process app on a supported Windows platform with current .NET Framework 4.8.1 servicing; runtime 1.x does not support the isolated worker model.
  • Verify through authenticated administration that the v1 host build Azure reports is no older than the newest 1.x release on the Azure Functions host releases page; never expose the master key or /admin/host/status URL in logs or diagnostics.
  • Keep <AzureFunctionsVersion>v1</AzureFunctionsVersion> and the runtime, SDK, project, and deployment settings consistent; changing only the host setting is not a safe migration.
  • Let Azure apply every serviced v1 host update selected by ~1; do not freeze a private host extension unless an owner continuously tracks, tests, and deploys v1 security servicing.
  • Treat every remaining v1 deployment as unsupported, isolate it, and complete a tested migration to runtime 4.

HTTP functions and v1 webhooks

  • Set authLevel explicitly on every non-webhook HTTP trigger: use function as the minimum shared-key gate, reserve admin for operations that truly require the master key, and use anonymous only behind a deliberate authenticated