Forum Discussion

curious7's avatar
curious7
Brass Contributor
Oct 13, 2026

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

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?

api management
azure
networking

2 Replies

  • Brent1455's avatar
    Brent1455
    Copper Contributor
    Oct 22, 2026

    curious7​ 
    Just checking in to enquire about the answer and question my Question to you, "If your policy requires the developer portal itself to be private or reachable only through your WAF, this gateway-only Private Link design does not satisfy that requirement. Is that your requirement, or is an authenticated public portal acceptable?"

  • Brent1455's avatar
    Brent1455
    Copper Contributor
    Oct 21, 2026

    Standard v2 can be viable if your requirements allow a publicly reachable developer portal protected by authentication. I would not treat subscription approval alone as sufficient to secure the whole setup.

    Microsoft documents inbound Private Link support for the gateway endpoint only. A private gateway therefore does not make the managed developer portal private. Likewise, a custom portal domain does not establish that the default portal endpoint is blocked.

    For this design, I would:

    1. Require portal sign-in using Microsoft Entra ID. Under Developer portal > Identities > Settings, enable the option to redirect anonymous users to the sign-in page.
    2. Keep subscription approval, and separately enforce the API's authentication and authorization requirements. For OAuth-protected APIs, configure the test console to obtain tokens and validate those tokens and their claims at the gateway or backend. Configuring OAuth in the console does not automatically enable token validation.
    3. Limit test-console token scopes to what developers need. Be especially careful with client-credentials flow, because Microsoft warns that tokens can be exposed through the console. For production-changing operations, I would provide a sandbox API for exploration.
    4. If gateway traffic must pass through your WAF, disable direct public gateway access after configuring Private Link and verify the intended route.

    If your policy requires the developer portal itself to be private or reachable only through your WAF, this gateway-only Private Link design does not satisfy that requirement. Is that your requirement, or is an authenticated public portal acceptable?

    Microsoft references:
    https://learn.microsoft.com/azure/api-management/private-endpoint
    https://learn.microsoft.com/azure/api-management/secure-developer-portal-access
    https://learn.microsoft.com/azure/api-management/api-management-howto-oauth2