The edge of a cloud architecture is part of the application architecture. Putting Cloudflare in front of an Azure-hosted application improves the public entry point, but the design is incomplete if users can still bypass Cloudflare and reach the origin directly.
The problem
A common deployment starts simply: an application runs on a public cloud virtual machine, Nginx serves the frontend and proxies API traffic, and DNS points users toward the application. Adding Cloudflare provides an additional edge layer, but the Azure origin may still remain publicly reachable through its IP address.
That creates two paths into the system: the intended path through Cloudflare and a second path directly to the origin. If the direct path remains open, controls applied at the edge can be bypassed.
The target architecture
Internet ↓ Cloudflare ↓ Azure Network Security Group ↓ Nginx ↓ React + Node.js API
The objective is straightforward: normal web traffic should reach the origin only after passing through Cloudflare. Administrative access such as SSH follows a separate, tightly restricted path.
1. Put Cloudflare in the public request path
The application domain is proxied through Cloudflare rather than exposing the Azure virtual machine as the normal client-facing endpoint. Cloudflare becomes the public web entry point while Azure remains the application origin.
This distinction matters because DNS proxying alone does not automatically make the origin private. Network access to the origin still needs to be controlled separately.
2. Restrict the Azure origin
The Azure Network Security Group can restrict HTTP and HTTPS traffic so that the origin accepts web requests from Cloudflare's published network ranges rather than from the entire internet.
SSH should be treated differently. Instead of exposing port 22 broadly, administrative access can be restricted to a known administrator IP or replaced later with a more controlled access mechanism.
Design principle An edge security layer provides much less value when the protected origin remains independently reachable from the internet.
3. Use Nginx as the application gateway
Nginx provides a clean boundary between incoming web traffic and the application processes running on the server. Static React assets can be served directly while API requests are forwarded internally to the Node.js application.
Browser → Cloudflare → Azure → Nginx
Nginx → React static files
Nginx /api/* → Node.js on 127.0.0.1:5000
Binding the Node.js service to the loopback interface means the application server does not need its own public network exposure. Nginx is the controlled gateway into the API.
4. Keep TLS valid between Cloudflare and the origin
HTTPS should not terminate at the edge and then fall back to an unverified connection to the origin. Cloudflare Full (strict) mode allows the connection between Cloudflare and Nginx to remain encrypted while requiring a valid origin certificate.
This provides a clearer trust model: HTTPS from the visitor to Cloudflare and HTTPS again from Cloudflare to the Azure origin.
5. Add browser-facing security controls deliberately
Nginx is also a suitable place for browser-facing response headers such as content type protection, framing restrictions, referrer policy, permissions policy and Content Security Policy.
Content Security Policy deserves particular care. Analytics, tag-management and other legitimate integrations should be explicitly allowed rather than weakening the policy broadly just to make a third-party script work.
What this architecture improves
The result is not that the virtual machine becomes magically private. It is that the public application path becomes intentional and layered. Cloudflare handles the edge, Azure controls which networks can reach the origin, Nginx controls application ingress, and the Node.js process remains internal to the server.
Each layer has a distinct responsibility, which makes the system easier to reason about and reduces accidental exposure.
Operational considerations
Restricting an origin also creates operational responsibilities. Cloudflare network ranges can change, so allowlists must be maintained. Logging should preserve the real visitor address correctly when requests pass through a proxy. Backups, monitoring, patching and recovery remain necessary even when the network perimeter is improved.
Security architecture should therefore be treated as an operational system rather than a one-time firewall configuration.
The broader engineering lesson
Infrastructure security works best when the request path is designed as part of the application architecture. CDN settings, firewall rules, reverse proxies, application bindings and browser security policies are related controls, not independent checkboxes.
The useful question is not simply, “Is Cloudflare enabled?” It is, “What exact path can a request take from the internet to the application, and which controls apply at every boundary?”
Origin-security review checklist
Before treating this pattern as production-ready, verify the whole request path rather than checking only whether Cloudflare proxying is enabled.
- Origin reachability: confirm that HTTP and HTTPS ingress is restricted to the intended sources. Test from an authorized external network and verify that direct-origin requests fail as expected.
- Administrative access: keep SSH separate from public web ingress and restrict it to an approved access path.
- TLS mode and certificate: verify the Cloudflare-to-origin TLS mode and certificate validity, expiry monitoring, and renewal process.
- Proxy trust: configure Nginx to trust forwarded client-IP headers only from known proxy ranges. Do not accept arbitrary client-supplied forwarding headers as the real visitor address.
- Firewall maintenance: maintain an owner and update process for Cloudflare IP ranges; stale allowlists can cause outages, while overly broad rules weaken the boundary.
- Application exposure: bind internal services to loopback or private interfaces where appropriate and confirm that unused ports are not publicly reachable.
- Security headers: test Content Security Policy and other response headers against the actual application and integrations. Avoid adding broad exceptions without understanding the impact.
- Observability and recovery: confirm that logs, alerts, backups, patching, and recovery procedures still work through the proxy path.
This is a review checklist, not a substitute for a threat model or a configuration-specific security assessment. Network rules and test procedures must match the actual cloud environment.
Related production-engineering reading
Origin security is one part of production readiness. For the wider operational picture, see the production-readiness approach for safe Azure AKS upgrades and SLO and error-budget planning. These cover adjacent concerns: controlled change, reliability objectives, and the operational signals used to judge whether a system is healthy.