What would you check before exposing a .NET API on App Service under a production domain?

What production boundary checks matter for an App Service web API?

Covers custom domains, TLS, HTTPS, allowed hosts, CORS boundaries, and production-facing endpoint hygiene for App Service APIs.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would treat the custom domain as part of production behavior, not as cosmetic DNS. I would verify the App Service binding, DNS records, TLS certificate, HTTPS-only behavior, redirect rules, allowed hosts, exact CORS origins, auth callback URLs, webhook URLs, and any generated absolute links. I would also smoke test the public domain from outside Azure, because the default azurewebsites.net host can hide problems that only appear on the real domain.

Full answer below

Practice focus

Production edge readiness, TLS, domain setup, HTTPS behavior, CORS, host restrictions, and client-facing API safety.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A production domain changes how TLS, proxies, cookies, CORS, callbacks, webhooks, redirects, and generated links behave. The public edge must be configured and tested as part of the application boundary rather than treated as a cosmetic DNS change.
I would treat the custom domain as part of production behavior, not as cosmetic DNS. I would verify the App Service binding, DNS records, TLS certificate, HTTPS-only behavior, redirect rules, allowed hosts, exact CORS origins, auth callback URLs, webhook URLs, and any generated absolute links. I would also smoke test the public domain from outside Azure, because the default azurewebsites.net host can hide problems that only appear on the real domain.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would check the whole edge path: whether traffic comes directly to App Service or through Front Door, Application Gateway, a CDN, or another proxy. That means forwarded headers, original scheme, client IP logging, secure cookies, SameSite behavior, CORS, HSTS, and any path base rewriting need to match the real public route. I would keep certificate renewal ownership and DNS change ownership clear, and I would test external integrations that call back into the API before exposing the new boundary to users.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Leaving permissive CORS because it fixed a local frontend error.
Testing only the default Azure hostname.
Forgetting auth callback and webhook URLs during domain changes.
No owner for certificate renewal or DNS changes.

What would you check before exposing a .NET API on App Service under a production domain?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement