Secure Azure Static Web Apps with IP Rules and Conditional Access
Technical review: 26 October 2026. Product names, licensing references and procedures reflect this review; check the linked documentation for your release.
“Only approved office IPs may use this application” can mean two different requirements: reject web requests from other sources, or prevent sign-in from other networks. Azure Static Web Apps networking rules and Microsoft Entra Conditional Access operate at different layers. Choose and test the control that matches the actual requirement.
Document both access decisions
Start with the approved public egress ranges, the app’s hosting plan and the Entra Enterprise Application used for sign-in. Private client addresses are usually not the addresses observed by an internet-facing service. VPNs, access proxies, IPv6 and cloud egress can change the source seen by each control.
Use fictitious documentation ranges in examples and keep the actual allowlist in the approved configuration repository. Record who owns it and how changes are communicated. An allowlist without an owner can become an outage when the network team changes an egress address.
Restrict web requests at the hosting layer
For supported Static Web Apps plans, the networking.allowedIpRanges configuration restricts requests by source range. It belongs in the complete deployed staticwebapp.config.json, not an unrelated App Service access-restriction screen. The service performs an HTTP access check; do not describe it as a guarantee that an outside client can never establish any TCP connection to the platform.
Review plan availability, IPv4/IPv6 support and any proxy integration in the current documentation. Deploy through the normal review pipeline and retain the prior configuration. Make sure the config reaches the build output, then test a direct request from an allowed source and a source that should be denied.
Add identity-based network policy deliberately
In Entra, use the relevant named location and a policy scoped to the intended Enterprise Application. Define the allowed-location or blocked-location logic explicitly; include/exclude selections can reverse the outcome if read carelessly. Follow the organization’s emergency-access exclusions and applicable licensing requirements.
Start in report-only mode and inspect representative sign-in results before enforcement. Conditional Access controls identity access; it is not a substitute for protecting anonymously reachable files or APIs. Existing sessions and token behavior also need to be considered when testing an access change.
Use a four-case acceptance test
| Source and user | Expected result to verify |
|---|---|
| Allowed source, approved user | Protected application works. |
| Allowed source, unauthorized user | Application sign-in or authorization is denied. |
| Disallowed source, approved user | The intended hosting and/or identity restriction denies access. |
| Disallowed source, no session | Protected content remains unavailable directly. |
Check the application hostname, preview paths and backend entry points included in scope. A green sign-in log does not prove that the network rule is correct, and an HTTP denial does not prove that the Conditional Access policy matched. Keep those observations separate in the closure record.
If enforcement breaks legitimate access, use the recorded recovery route for the affected layer rather than removing every control. The Static Web Apps SSO guide covers the underlying application sign-in configuration.
References
- Microsoft: Static Web Apps networking configuration
- Microsoft: Conditional Access location policies
- Microsoft: Conditional Access report-only mode