Two approaches to edge security.
Cloudflare protects the path. NetSpectra removes the path entirely.
Both are valid approaches to edge security. They trade off different concerns. This page is a fair technical walkthrough of how each works and which problems each solves best. We are not claiming to be more secure — we are claiming to be different, and explaining the difference honestly.
What both systems try to do.
Both Cloudflare and NetSpectra exist to protect origin systems from direct exposure to the public internet. The question is how that protection is structured — where attack surface lives, who maintains it, and what happens when it fails.
Cloudflare — fair description.
Cloudflare sits between your visitors and your origin server. It terminates TLS, runs WAF rules, caches static content, and forwards legitimate traffic to your origin. Your origin stays in place, reachable by Cloudflare IPs (and, if misconfigured, by anyone).
- Argo Tunnel— origin has no open ports at all; traffic flows through a persistent outbound tunnel to Cloudflare's edge.
- Authenticated Origin Pulls— origin rejects connections that don't carry a valid CF client certificate.
- Origin CA + strict firewall— origin is only reachable from CF IP ranges, authenticated at the TLS layer.
- Mature WAF and DDoS— years of tuning, massive capacity, well-known threat intelligence.
A properly configured Cloudflare setup with Argo Tunnel and Authenticated Origin Pulls is genuinely strong protection. The challenge is that most Cloudflare deployments don't use these features, and even when they do, the configuration has to be maintained continuously as your infrastructure evolves.
NetSpectra — fair description.
NetSpectra takes a different path. Your origin has no public web service at all. No 443/tcp. No HTTPS endpoint. The HTTPS service runs on our edge, which terminates TLS, fingerprints the connection, makes a decision, and forwards legitimate traffic to your origin through a persistent WireGuard tunnel.
- Your origin has no HTTPS service on its public interface. Web scanners have nothing to target there.
- Configuration burden moves to our edge. You don't maintain firewall rules, CA certs, or tunnel configuration — we do.
- Backend code quality no longer determines your public attack surface. Bugs in your application can only be triggered through verified traffic.
- Attacks concentrate on our edge. One hardened system, one patch schedule, one team responsible for keeping it secure.
This is not more secure in absolute terms. It is a different trade-off: you delegate configuration and attack surface management to us. In exchange, your origin becomes structurally isolated from the public internet.
Moved, not eliminated.
This is the key honest reframe. Nobody eliminates attack surface. You move it, concentrate it, and control it. The difference between the two approaches is where the surface lives and who is responsible for it.
Traditional (no edge):
Internet ───► Backend (exposed)
▲
└── attack surface here
Cloudflare (properly configured):
Internet ──► CF Edge ─────► Backend
▲ ▲
└─ primary └─ fallback if CF misconfigured
attack
surface
NetSpectra:
Internet ──► Our Edge ──[WG]──► Backend (isolated)
▲
└── only attack surfaceThe nine known discovery vectors.
Here are the nine documented ways to discover a Cloudflare-protected origin IP when the deployment is not hardened. These vectors do not apply to NetSpectra deployments because the origin has no public web service to begin with — but they illustrate the configuration burden that CF places on the client.
Historical DNS records
Services like securitytrails.com and viewdns.info archive old A records indefinitely. If your origin IP was ever in public DNS before CF migration, it remains findable.
SSL certificate transparency logs
crt.sh and similar tools index every certificate ever issued for your domain. Pre-CF certificates or Let's Encrypt certs on origin remain searchable forever.
Subdomain leak
Subdomains like mail.*, ftp.*, api.*, dev.* are often forgotten behind CF. Their A records leak the real origin IP.
Email header analysis
Outgoing mail from origin reveals its IP in SMTP headers. Transactional mail, password resets, notifications — any of these expose the IP.
Favicon and content hash search
Shodan indexes internet-facing services by SHA256 of favicon and response content. Your unique favicon or homepage becomes a search key.
SSRF in origin-hosted services
If origin has any service making outbound requests (webhooks, image proxies, URL previews), it can be tricked into hitting attacker-controlled URLs that log the IP.
Historical DDoS IP disclosure
CF has occasionally revealed origin IPs in response headers during extreme load events. Rare today, but historical incidents remain in archived data.
Internet-wide scanning
Censys, Shodan, Fofa and similar services continuously index the entire IPv4 space. If your origin serves identifiable content or SSL certificates, they find it.
WordPress XML-RPC and similar callback vectors
Legacy endpoints like XML-RPC pingback can be triggered by an attacker to force the origin to actively connect to an attacker-controlled URL.
Which approach fits which adversary.
Security is always relative to what you're defending against. Here's how both approaches fare against standard adversary tiers.
Script kiddies with off-the-shelf tools
Protected by default — CF blocks basic scans and common web attacks.
Protected by architecture — their tools look for HTTP services that don't exist on your backend.
Targeted attackers with standard toolset
Protected when configured correctly. Vulnerable if Origin Pulls or firewall are missing.
Protected. Attack surface is our hardened edge. Your backend is not in their scope.
Advanced actors with custom tools
Attacker probes CF edge and any exposed origin. CF has strong anti-bot signals but a determined custom attacker can reach origin if any vector is open.
Attack surface moves to our edge. Your backend remains isolated. Attacker must find and exploit our edge specifically.
State-level actors with significant resources
No commercial product defends completely. CF offers many layers of mitigation and visibility.
No commercial product defends completely. We offer isolation, time cost, and observable concentration of attack traffic.
Our limitations — stated honestly.
Every architecture has trade-offs. Here are ours, described without spin.
Single point of trust
When you use NetSpectra, you trust us with all your inbound traffic. A compromise of our edge affects all clients identically. This is the same trade-off you make with any managed edge service (including Cloudflare), but it's worth naming explicitly.
The edge is the attack target
We moved attack surface, we did not delete it. Our edge is the new target. We mitigate this through hardened design (Ada/SPARK crypto core, formal verification, constant-time operations), but a serious bug in our code still has consequences.
WireGuard is not invincible
Our visible UDP port resists enumeration, key brute force, and fingerprinting. The remaining vectors — UDP flood, handshake CPU exhaustion, implementation CVEs — are mitigated but not eliminated. This is attack surface minimized and controlled. It is not zero.
You delegate configuration, you don't eliminate it
With CF, you configure Argo, Authenticated Origin Pulls, firewall, WAF rules. With us, you don't — but you accept our defaults. If our defaults don't fit your use case, the burden shifts to conversations with us, not self-service configuration.
Which should you choose.
This is not a trick question, and we're not going to answer “NetSpectra” by default. The honest answer depends on what you're solving.
- Your team can reliably maintain Argo Tunnel and Authenticated Origin Pulls
- You need CF's massive caching and CDN footprint
- You need mature WAF with well-known rule sets
- Your compliance requirements specifically name CF
- Global CDN is your primary need, bot detection secondary
- You want origin structurally isolated from the public internet
- You don't want to maintain edge configuration yourself
- Your backend has services you'd rather not expose to scanners
- Bot detection is a primary concern, not a side feature
- You value formally verified crypto and want to know how it works
// BOTH ANSWERS ARE CORRECT FOR DIFFERENT ORGANIZATIONS · UNDERSTAND THE TRADE-OFF HONESTLY
There is only fits what you're trying to protect against.