Is APIM Standard_V2 tier viable option from security standpoint if you have Developer portal enabled

Question

Is APIM Standard_V2 tier viable option from security standpoint if you have Developer portal enabled

curious7 281

From my understanding with APIM Standard_v2 tier you can only configure the gateway endpoint with private endpoint and have that behind something like application gateway to allow the ability to have WAF in front of it. But, the developer portal is reachable only over its public address and cannot have private endpoint.

Even after adding a custom domain on the Developer portal endpoint, the default <name>.developer.azure-api.net address keeps responding and returns 200.

If you set all your APIs to require approval for subscription , then for a production scenario where you would allow "Try this operation" functionality on your APIs through developer portal, is it safe to still use standard_v2 tier. Or are there some security problems associated with that?

0 comments

2 answers

Your answer

Answer 1

Welcome to Microsoft Q&A

Hello @curious7 I hope you are doing well,

Your understanding is correct. In Standard_v2, the Gateway endpoint is the only component that supports inbound Private Link. The Developer Portal does not support a private endpoint, so it remains publicly accessible.

From a security perspective, Standard_v2 can still be a viable production option provided you are comfortable with the Developer Portal being internet-reachable. The main concern is not that the portal is public, but how it is configured:

Require authentication for portal access.
Disable anonymous user capabilities where possible.
Require subscriptions/approval for API access.
Use Microsoft Entra ID for authentication instead of local accounts.
Ensure backend APIs are protected independently and do not rely solely on portal access restrictions.

One important limitation is that even after configuring a custom domain, the default:

<name>.developer.azure-api.net

Endpoint continues to respond. If your requirement is that all APIM surfaces (gateway, management, and developer portal) be privately accessible or protected by your own WAF, then Standard_v2 may not meet your security requirements.

So my rule of thumb would be:

Yes, Standard_v2 is viable if a public Developer Portal is acceptable and access is properly authenticated and governed.
No, Standard_v2 is not ideal if your security policy requires complete network isolation of the Developer Portal or inspection through a private WAF-controlled path.

References

Set up inbound private endpoint for Azure API Management learn.microsoft.com Private Enpoint
Azure API Management with an Azure virtual network docs.azure

If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find similar solutions.

Answer 2

Standard v2 is viable if a publicly reachable developer portal is acceptable, but it is not suitable when the portal itself must be private or reachable only through your WAF because inbound Private Link supports only the APIM Gateway endpoint.^1^

Recommended production configuration

Privatize the API gateway
- APIM → Deployment + infrastructure → Network → Edit.
- Under Inbound features, create a private endpoint with Gateway as the subresource.
- Enable private DNS integration.
- After the connection is approved, set Public network access to Disable.
Standard v2 supports this gateway-private-endpoint configuration, and public access can be disabled only after the private endpoint exists.^1^
Route external API traffic through the chosen edge
- Application Gateway/WAF or Azure Front Door can receive public API traffic and forward it privately to the APIM gateway.
- Apply WAF controls at that edge and APIM authorization, validation, throttling, and quotas at the gateway. Microsoft’s APIM security guidance recommends reducing gateway exposure and using gateway policies for API-specific security.^2^
Treat the managed developer portal as a separate public web application
- Configure its custom domain and certificate.
- Republish it after changing the domain: APIM → Developer portal → Portal overview → Publish.
- Require authentication: APIM → Developer portal → Identities → Settings → enable Redirect anonymous users to sign-in page.
- Prefer Microsoft Entra ID or Microsoft Entra External ID over built-in username/password authentication.^3^
- Enable a Content Security Policy under Developer portal → Portal settings → Content security policy and allow only required origins.^4^

About the default developer-portal hostname

The documented behavior is that, unlike the gateway endpoint, the default developer-portal endpoint should no longer be available after a developer-portal custom domain is configured.^5^

Since the default hostname still returns 200:

Republish the portal after the custom-domain change; portal-affecting APIM configuration changes require republishing.^4^
Test a specific published page from a new browser session, not only /; record the response body, headers, certificate, and whether it is the current portal.
If the current published portal remains accessible through both hostnames after republishing and the APIM update has completed, open an Azure support request. That result conflicts with the documented custom-domain behavior; do not assume the custom hostname has removed the default endpoint until testing confirms it.

Even if the default hostname is removed, the custom developer-portal hostname remains public in Standard v2. A custom domain changes the hostname and certificate; it does not provide Private Link or place the portal behind Application Gateway.

“Try this operation” security

Requiring subscription approval is useful but is not sufficient production authorization. A subscription key identifies an APIM subscription, not a user or application, and it can be shared or leaked. Microsoft recommends OAuth 2.0 or client certificates for authentication, with subscription keys used only as coarse access control.^2^

For production:

Require portal sign-in.
Require administrative approval for product subscriptions.
Configure the test console to obtain an OAuth 2.0 token for the signed-in developer.^6^
Validate the token, issuer, audience, and required claims at the APIM gateway.
Apply rate limits, quotas, request validation, and backend authorization.
If using a custom portal domain with the interactive console, add that origin to the API CORS policy or use the documented portal CORS proxy where appropriate.^7^

Decision

Viable: Internet-facing developer onboarding is intended; portal authentication and content controls are applied; API calls require OAuth/client-certificate authorization; the gateway is private and externally exposed only through the controlled edge.
Not viable for the requirement: The managed developer portal itself must have a private endpoint, be network-private, or all portal traffic must traverse your WAF. Standard v2 does not provide that topology. Consider a tier/networking model supporting an internal developer portal, or self-host a separate portal architecture after assessing its additional operational and security responsibilities.

References