Security guidance
Use App Service Builder Private Preview for development and test only. Do not deploy production workloads or give experimental code access to production data. Review the Azure Preview terms and preview guidance.
Separate the trust boundaries
| Boundary | What to configure |
|---|---|
| Managing the Azure resource | Azure account, subscription/resource group, and the appropriate Builder App RBAC permissions |
| Reading and building source | Separately authorized GitHub repository and source root |
| Visiting the deployed app | App authentication and application-level authorization |
| Calling Azure dependencies | Managed identity or other server-side credentials, least-privilege destination permissions, and network reachability |
| Calling external APIs | Server-side credentials, scoped service permissions, and a trusted destination |
An account that can view an app does not necessarily have permission to reveal variables or modify it. Management sign-in is not visitor authentication. See access and sign-in.
Protect source and configuration
Keep credentials out of Git, builder.yaml, sample repositories, and frontend bundles.
All variable values are sensitive; ordinary app reads omit them, while the separately authorized listVariables action can return them.
Limit who can call that action.
Variables are captured in versions, so activating a retained version restores its historical variable snapshot.
If a credential leaks, rotate it at the issuing service and review retained versions before reactivation; deleting it from current configuration does not revoke it.
Static builds can embed configuration into publicly readable output. Use a backend for secrets and enforce authorization there. Protect build scripts and dependency changes through source review: build code receives version variables.
Protect requests and tool actions
Deployed-app authentication establishes caller identity; your app must still authorize its operations. Trust identity headers only when requests come through Builder's protected app endpoint. An agent or application tool that can read data or perform writes needs explicit permission checks, input validation, bounded execution, and any required human approval. Visitor sign-in alone is not approval for a cloud write.
Apps call Azure services with a managed identity rather than stored keys. Assign destination permissions at the narrowest useful scope and use a separate development identity. An identity assignment does not bypass firewalls or create private connectivity.
Verify before sharing
Check the app URL both without credentials and with an authorized caller. Verify rejection for an unauthorized caller, not just successful sign-in. Check browser assets and sanitized logs for accidentally exposed values. Review networking, storage, and the effective preview limits. Builder's preview scope does not inherit App Service features, compliance claims, networking options, or SLA by product name.