Azure Functions Security Review
An HTTP trigger set to anonymous, or a host key shared too widely, skips Azure’s access check entirely. We test the authorisation levels, keys, identities and settings your team configured. CREST-certified testers, fixed price from £3,350 for a 3-day single-estate scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
Azure Functions ships four scopes of access key, from a single function up to the master key, which Microsoft treats as an administrative credential able to deploy and run code through the runtime’s REST APIs.
An Azure Functions app is only as isolated as the keys, identities and settings your team actually configured
Every HTTP-triggered function is set to an authorisation level of anonymous, function or admin, and Microsoft’s own documentation on access keys is explicit that unless a function is set to anonymous, callers must supply a key as a ?code= query parameter or an x-functions-key header. Those keys come in four scopes: a function key that reaches only its own endpoint, a host key that reaches every function in the app, a system key reserved for extension webhooks, and the master key, an administrative credential capable of deploying and running code through the runtime’s REST APIs. Which authorisation level each function actually uses, how widely a host or master key has been shared, and whether a key was ever rotated after being exposed is a decision your team made, not an Azure default.
Access to everything a function calls out to is a second, separate decision. Connection strings and secrets are stored as application settings by default, encrypted by Azure and decrypted only into the app’s process memory at startup, or as references to Azure Key Vault if your team chose that route instead. Where a binding supports it, Microsoft recommends a system-assigned or user-assigned managed identity in place of a secret, and its own guidance on identity-based connections warns against granting a broad built-in role such as Owner “even just to get the app to work”. We test which application settings still hold a live secret in plain form, whether a managed identity’s role assignment gives it more reach than the binding needs, and whether a Key Vault reference is resolving correctly or silently falling back.
We test the function app you actually deployed on Microsoft’s runtime: its triggers, authorisation levels, keys, application settings, managed identities and the storage account behind it, never Azure Functions’ own hosting platform. Azure Functions splits out of our wider serverless and Lambda security review because its keyed HTTP triggers and identity-based bindings work differently to a Lambda function’s IAM execution role, and the wider configuration of your Azure subscription, Entra ID tenant and networking is covered separately in our Azure cloud security review.
SCOPE
What we test on a single Azure Functions estate
HTTP Trigger Authorisation Levels and Access Keys
Every HTTP-triggered function is set to an authorisation level of anonymous, function or admin, and unless it is anonymous, Microsoft requires the caller to present an access key as a ?code= query parameter or an x-functions-key header. Access keys come in four scopes: a function key that reaches only its own endpoint, a host key that reaches every function in the app, a system key reserved for extension webhooks, and the master key, which Microsoft describes as an administrative credential able to deploy and run code through the runtime’s REST APIs. We test which authorisation level each function actually uses, how widely host and master keys have been shared, and whether a key was ever rotated after being exposed.
App Service Authentication in Front of the Function App
App Service Authentication, commonly called Easy Auth, lets a function app authenticate callers with Microsoft Entra ID or a non-Microsoft identity provider before a request reaches your code, and Microsoft positions it as the base for building custom authorisation rules on top. Turning Easy Auth on for one function app in a subscription while leaving a sibling app on anonymous or key-only access is a configuration choice, not a platform default. We test whether Easy Auth is actually enforced where your team intended it, which identity providers are configured, and what a request can still reach if it bypasses the Easy Auth layer.
Managed Identities and What They Can Reach
A function app can call other Azure services using a system-assigned or user-assigned managed identity instead of a stored secret, and Microsoft’s guidance on identity-based connections is explicit that the identity still needs an Azure RBAC role assignment to do anything, warning teams not to use a broad built-in role such as Owner even just to get the app to work. Which role each identity actually holds, and whether it reaches further than the one binding it was created for, is set by whoever assigned that role. We test every managed identity attached to the function app against the RBAC roles it actually holds and what those roles let it read, write or delete.
Secrets in Application Settings vs Key Vault References
By default, a function app stores connection strings and secrets as application settings, which Azure encrypts and decrypts only into the app’s process memory when it starts, rotating the encryption keys regularly. Microsoft’s own alternative for teams who want to manage secrets themselves is to replace those application settings with references to Azure Key Vault. Which of your app’s settings hold a live secret in plain form, and which have actually been moved to Key Vault, is a decision made setting by setting. We test every application setting for an exposed secret and check whether a Key Vault reference is resolving correctly.
AzureWebJobsStorage and the Function App’s Storage Account
Every function app must be linked to a general-purpose Azure Storage account that backs its Blob, Queue and Table storage, and by default that connection is stored as a single AzureWebJobsStorage application setting with full access to the account. Microsoft’s identity-based alternative still needs the Storage Blob Data Owner role, which its documentation calls the minimum permission the Functions host needs, plus a separate Storage Table Data Contributor role for diagnostics. We test what the AzureWebJobsStorage credential or identity can actually reach in that storage account beyond what the function’s own triggers and bindings need.
Non-HTTP Triggers: Queues, Blobs and Event Grid
A queue, blob or Event Grid trigger fires on whatever lands in the bound storage account or Event Grid topic, and Microsoft’s own key reference notes that some extensions use a separate system key rather than a function, host or master key to secure their webhook endpoint. Whoever can write to that queue, drop a blob in that container or publish to that Event Grid topic can invoke the function, whether or not they hold an HTTP access key. We test who can reach each trigger’s upstream source, and whether the function trusts the content of an incoming message further than the source can actually be trusted.
Downstream Data Access from Function Code
A function’s code inherits whatever the AzureWebJobsStorage connection, any additional binding connections and any managed identity role assignments allow it to reach, independently of the trigger that started it. A function built to read one queue can still hold a connection string or identity with write access to an entire database, storage account or downstream API if that is what was configured. We test what each function can actually read, write or delete once it is running, not just what its trigger is meant to respond to.
CORS Configuration on the Function App
CORS rules for a function app’s HTTP endpoints are defined once at the function-app level, and Microsoft’s own guidance warns against the shortcut of allowing every origin, because a wildcard defeats the purpose CORS is meant to serve. A rule added for one front end during development and never narrowed can leave every HTTP-triggered function reachable from any site a browser loads. We test the configured CORS origins against what your application actually needs and what a site outside that list could still do.
Network Access Restrictions and Private Endpoints
Access restrictions let you build allow and deny rules that are evaluated in priority order, and Microsoft is explicit that a function app with no rules configured accepts traffic from any address. On the Flex Consumption, Elastic Premium and Dedicated plans, Microsoft also supports Private Endpoint, bringing the function app inside your virtual network on a private IP address instead of a public one. We test what your configured access restrictions actually allow, and whether a private endpoint deployment still leaves a public endpoint reachable alongside it.
Deployment: SCM/Kudu Access and Publishing Credentials
Every function app has its own scm endpoint, used by the Kudu-based Advanced Tools service for deployment, and Microsoft confirms that endpoint accepts both basic authentication using deployment credentials and single sign-on with your Azure portal credentials. Deployment credentials come as user-scope credentials tied to one Azure account across every app it can reach, or app-scope credentials generated automatically for a single app and retrievable by anyone holding at least Contributor-level access to it. We test who can reach the scm endpoint, which deployment credentials are still active, and what a leaked set can deploy or run.
OUR PROCESS
Azure Functions Security Review: From Scope to Attestation
Scope and Access
We agree which function apps, environments and trigger types are in scope, plus a function, host or Easy Auth account for each authorisation level you use.
Key, Identity and Settings Mapping
We map every access key, managed identity, RBAC role assignment and application setting against what it can actually reach.
Manual Testing
A CREST-certified tester manually tests trigger authorisation, key scope, managed identity boundaries, Key Vault references, CORS and network access restrictions, chaining findings where they compound.
Attestation and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST Azure Functions pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Azure Functions Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
3 to 4 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote6 to 8 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test Azure Functions For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Azure Functions Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our Azure Functions estate?
We need read access to the function app’s configuration, including its HTTP trigger authorisation levels, application settings and any managed identities and RBAC role assignments attached to it, plus at least one access key or Easy Auth account for each authorisation level in use. Deployment or portal write access is not required to start; we only need it if a finding needs verifying by making a configuration change.
Will testing touch our live data?
Testing focuses on the function app’s triggers, keys, identities, application settings and storage account configuration rather than the business data your functions process. Where proving a finding needs a test message, blob or queue entry, we agree the exact scope with you first and remove anything we create once testing is complete.
Is this hosted on our infrastructure or Microsoft’s?
Azure Functions is a Microsoft-hosted serverless platform, so there is nothing for you to host. The engagement is scoped to the function app configuration you control: authorisation levels, keys, managed identities, application settings, storage account access and deployment credentials, not to the underlying Azure Functions runtime.
How long does an Azure Functions security review take?
A single estate with a typical number of function apps, triggers and one storage account sits in our 3-day single-estate scope, with a report usually landing around 5 working days after kickoff. An estate spanning several function apps, multiple storage accounts or a mix of HTTP and non-HTTP triggers extends that scope.
What is out of scope for a single-estate review?
Testing the underlying Azure Functions runtime, its host infrastructure or Microsoft’s own platform is never in scope, and we do not run denial-of-service testing against any Azure service. A downstream Azure service such as a database or API that a function calls into is scoped and quoted as its own engagement rather than bundled into the function app review.
Does Microsoft have a customer penetration-testing policy we need to follow?
Yes. Microsoft’s penetration testing rules of engagement for its cloud services confirm that customers do not need Microsoft’s pre-approval to test resources they own on Azure, including Azure Functions and API endpoints, though activities such as denial-of-service testing and using credentials that are not your own remain prohibited. We confirm Microsoft’s current rules of engagement and any account-specific conditions during scoping.
Do you need our source code or portal access?
No. We test with the access keys, Easy Auth accounts and read access to configuration that you provide, and we do not need standing Contributor or Owner-level portal access beyond what is needed to verify a specific finding during the engagement.
Are your testers CREST certified?
Yes. Every Azure Functions engagement is carried out by UK-based, CREST-certified testers, and your report and attestation letter are recognised by auditors and insurers accordingly.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Azure Functions estate
An HTTP trigger set to anonymous, or a host key shared too widely, skips Azure’s access check entirely. We test the authorisation levels, keys, identities and settings your team configured. CREST-certified testers, fixed price from £3,350 for a 3-day single-estate scope, quoted within 24 hours.
