Azure API Management Security Review
In Azure API Management, token checks, keys and rate limits are all policy XML inherited between scopes. We test what each policy actually inherits, and what a missing base element switches off. 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.”
A policy in Azure API Management can be set at five different scopes, global, workspace, product, API and operation, and every scope below the top only inherits the one above it if its policy still contains a base element.
A missing base element silently drops every policy inherited from a broader scope
Azure API Management lets you write a policy at five different scopes, global, workspace, product, API and operation, and Microsoft’s own policy documentation confirms that each scope only inherits the ones above it through a single base element in its inbound section. Remove that element while editing a lower scope and, in Microsoft’s own words, only the policies configured at that scope still apply; anything set at product level or broader, including a validate-jwt or validate-azure-ad-token check meant to cover the whole estate, simply stops running.
Subscription keys compound the risk because they identify the calling application rather than a person, and every instance ships with a built-in all-access subscription that Microsoft warns should never be used for routine API access or embedded in a client app, precisely because it reaches every API in the estate. The same documentation confirms that product-scoped policies are not applied at all to a request made with an API-scoped, all-APIs or the built-in all-access subscription, so the type of key in use can decide which policies actually run, not just which endpoints it can reach.
We test the estate you have configured: the policy inheritance chain across every product and API, the subscriptions and named values in active use, developer portal access, and how the backend authenticates and whether it can be reached without going through the gateway at all. We never test Azure’s own infrastructure, in the same way we test client configuration on Azure environments rather than Microsoft’s platform.
SCOPE
What we review on an Azure API Management estate
JWT and Entra ID Token Validation Placement
The validate-jwt policy checks a token’s issuer, audience, expiry and signing keys against an OpenID configuration endpoint, and Microsoft’s separate validate-azure-ad-token policy checks a token against a specific Entra ID tenant plus its own backend-application-ids and client-application-ids lists; both can be attached at the global, workspace, product, API or operation scope. We test which scope the check actually resolves to, whether every operation that needs a token has one attached somewhere in its inheritance chain, and whether the accepted audiences and application IDs match what should be allowed to call the API.
Policy Scope and Base Element Inheritance
Azure API Management lets a policy be set at the global, workspace, product, API or operation scope, and Microsoft’s documentation confirms that removing the base element from a scope’s inbound section means only that scope’s own policies apply, policies configured at product level and broader are not applied at all. We test every API and operation against its full inheritance chain to confirm a base element was not dropped while editing a lower-scope policy, silently switching off a check like validate-jwt that was meant to apply everywhere.
Subscription Keys and Product Boundaries
A subscription key identifies the calling application against a product or API rather than a person, and Microsoft’s documentation warns that the all-access subscription built into every instance grants access to every API and should never be used for routine access or embedded in a client app; it also confirms that product-scoped policies are not applied to requests made with an API-scoped, all-APIs or the built-in all-access subscription. We test which keys are actually live, whether the all-access key has reached a client or script, and whether a subscription type is quietly bypassing a policy your team believes is enforced at product level.
Developer Portal Sign-up, Anonymous Access and CORS
The developer portal ships with sign-in and sign-up links in its anonymous user menu that can be disabled per site, and Microsoft’s own setup guidance for the built-in test console tells owners to enable CORS on every API so a visitor’s browser can call it directly from the portal. We test what an anonymous or newly self-registered visitor can see and call before approval, whether sign-up should have been switched off for this estate, and whether the CORS configuration needed for the portal’s console has been widened further than the portal itself needs.
Direct Backend Reachability Bypassing the Gateway
Azure API Management is a gateway in front of a backend URL you configure, and nothing about attaching it stops that same backend being called directly if its own network and authentication are not locked down to accept traffic only from the gateway. We test whether the backend can be reached without the subscription key, token or client certificate the gateway is supposed to enforce, which defeats every policy configured in front of it.
Backend Authentication via Managed Identity or Client Certificate
A backend entity can require a header, query parameter, client certificate or the API Management instance’s own system-assigned or user-assigned managed identity, and Microsoft’s documentation is explicit that API Management obtains the Entra ID token and forwards it to the backend as-is without checking which backend it is sent to, leaving that trust boundary to whoever configures the backend. We test whether the configured credential type actually matches what the backend enforces, and whether a managed identity token or client certificate scoped for one backend could reach another.
Named Values and Key Vault Secret Exposure
Named values can hold a plain string, a secret encrypted by API Management, or a reference to an Azure Key Vault secret kept in sync by a managed identity, and Microsoft’s own caution notes that a Key Vault-backed secret referenced in a policy stays visible to any subscription enabled for API request tracing, and that anyone with permission to edit policies can read any named value’s contents through its {{name}} reference regardless of their access to the named value resource itself. We test which named values hold live secrets, who can enable request tracing, and whether policy-editing rights have quietly become secret-reading rights.
Rate Limiting and Quota Bypass
The rate-limit-by-key and quota-by-key policies each throttle against a counter-key you define, commonly a subscription key or client IP address, and Microsoft’s documentation confirms a single counter is shared across every scope configured with the same key value unless you deliberately vary it per scope. We test whether the counter key can be manipulated or rotated to reset a limit, and whether a quota meant to apply per subscription is actually being calculated from something an attacker controls, such as a spoofable header.
Network Isolation and VNet Connectivity Modes
API Management offers virtual network injection in external or internal mode, where the gateway, developer portal and management plane sit inside the network either way, and a separate outbound-only virtual network integration on the newer tiers, where Microsoft’s documentation confirms the gateway, developer portal and management plane remain publicly accessible from the internet even though the backend connection is private. We test which mode is actually deployed against which one the business believes is running, since assuming outbound integration hides the developer portal or gateway from the internet is a documented misreading of what that mode does.
Diagnostic Logging of Sensitive Data
Default API Management diagnostic settings do not log request or response bodies, but Microsoft’s documentation confirms a logged payload can be switched on and is capped at 8,192 bytes per entry, and separately that a Key Vault secret referenced by a policy becomes visible to any subscription with API request tracing enabled. We test what has actually been switched on in diagnostic settings and Application Insights, whether a token, key or Key Vault secret ends up captured in a log or trace, and who can read it once it is there.
OUR PROCESS
Azure API Management Security Review: From Scope to Attestation
Scope and Access
We agree which API Management instance, products, APIs and named values are in scope, plus at least one subscription key for every product boundary and any developer portal accounts needed.
Policy and Configuration Mapping
We map every policy’s actual scope and inheritance chain, the subscription types in use, named value and Key Vault references, and the configured virtual network or integration mode.
Manual Testing
A CREST-certified tester manually tests token validation placement, base element inheritance, backend authentication and reachability, rate limiting and developer portal access, 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 API Management 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 API Management 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 API Management 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 API Management 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 API Management estate?
We need at least one subscription key covering each product boundary in scope, plus a developer portal account if the portal itself is in scope. Read access to your policy XML, named values and backend configuration speeds up several checks, but is not required to start.
Will testing touch our live data?
Testing focuses on gateway policies, subscriptions, named values, developer portal access and backend configuration rather than the content flowing through your APIs. Where proving a finding needs a real call to a backend, we agree the exact test data and environment with you first.
Is this hosted on our infrastructure or Microsoft’s?
Azure API Management runs on Microsoft’s infrastructure in whichever region and network mode you have deployed, so there is nothing separate for you to host. The test is scoped to the instance configuration you control, policies, subscriptions, named values and backend settings, not to Microsoft’s underlying platform.
How long does an Azure API Management review take?
A single estate with a typical number of products, APIs and policy scopes sits within our 3-day single-estate scope, with a report usually landing around 5 working days after kickoff. An estate with more products, a deeper policy inheritance tree or several backend services extends that scope.
What is out of scope for a single-estate review?
Testing Microsoft’s own Azure infrastructure or the API Management platform itself is never in scope, and we do not run denial-of-service testing against any Azure service. A backend application that only happens to sit behind API Management, rather than the gateway configuration itself, is scoped and quoted as its own engagement.
Does Microsoft have a customer penetration-testing policy we need to follow?
Yes. Since 15 June 2017 Microsoft no longer requires prior notification or approval before you penetration test your own Azure resources, provided you follow Microsoft’s penetration testing rules of engagement for its cloud services, which prohibit denial-of-service testing and any activity against systems, tenants or data you do not own or have explicit permission to test. We confirm the current wording of that policy and any account-specific conditions for your estate during scoping.
Do you need our source code or admin access?
No. Most of what decides security in an API Management estate is configuration, policies, subscriptions and named values, rather than source code. We test with the subscription keys and portal access you provide, and do not need standing administrator access to the Azure portal beyond what is needed to verify a specific finding during the engagement.
Are your testers CREST certified?
Yes. Every Azure API Management 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 API Management estate
In Azure API Management, token checks, keys and rate limits are all policy XML inherited between scopes. We test what each policy actually inherits, and what a missing base element switches off. CREST-certified testers, fixed price from £3,350 for a 3-day single-estate scope, quoted within 24 hours.
