Here’s a thought experiment. You’ve deployed a WAF. You have an API gateway with rate limiting. You have DDoS protection. You’ve tuned your rules carefully. You’ve passed your last pen test.
Now open a browser tab and go to Shodan at https://shodan.io and search for your company’s IP range.
If your APIs have open inbound ports (and they almost certainly do, because that’s how APIs work), Shodan already knows about them. So do Censys, FOFA, and every automated attack tool that queries them on a schedule. Your WAF doesn’t prevent that, because it can’t. The WAF sits behind the port, not in front of it.
This isn’t a criticism of WAFs; they do what they were designed to do. The problem is that they were designed for a different threat model than the one you’re actually facing.
API Reachability is the Problem
Every API security conversation eventually converges on the same question: how do we tell good traffic from bad? Allowlists, blocklists, rate limits, bot detection, ML anomaly scoring…the entire industry is built around answering that question better and faster.
But there’s a more fundamental question that barely gets asked: why is your API reachable to everyone in the first place?
An open inbound port is a standing invitation. Before your WAF evaluates a single packet, before your gateway checks a single token, the attacker has already found your endpoint, confirmed it’s responding, identified the software version from the headers, and looked it up in their CVE database. All of that happens before authentication. Before your WAF sees a single byte of application-layer traffic.
The WAF model assumes that the hard problem is distinguishing legitimate requests from malicious ones. Identity-First Reachability™ takes the position that the hard problem is being reachable to malicious actors at all.
How Attackers Recon Your API Before Exploiting It
Most API attacks don’t start with a sophisticated payload; they start with reconnaissance. An attacker – or more commonly now, an automated tool running on behalf of an attacker – will:
1. Scan for reachable endpoints. Tools like Shodan, Censys, and FOFA continuously index every publicly reachable IP and port on the internet. Your API showing up in their results isn’t a security incident. It’s just a Tuesday.
2. Fingerprint the stack. Response headers, error messages, and timing characteristics tell a lot about what software is running. This narrows the relevant CVE list considerably.
3. Probe for known vulnerabilities. Automated exploit kits can test hundreds of known vulnerabilities in minutes — often without generating enough traffic to trigger WAF rate-limiting rules.
4. Attempt credential stuffing. If step three doesn’t yield results, leaked credential databases are enormous and cheap. A low-and-slow stuffing attack against a discoverable login endpoint is essentially free.
None of these steps require bypassing your WAF. They only require reaching your infrastructure. And your infrastructure is reachable, because it has to be to serve legitimate traffic. That’s the fundamental contradiction at the heart of every perimeter-based API security model.
What WAFs Can’t Protect Against
A WAF is excellent at what it does: inspecting application-layer traffic for known attack patterns, enforcing rate limits, blocking malformed requests, and providing a layer of defense-in-depth once a connection is established. But the operative phrase is once a connection is established.
By the time your WAF sees traffic, the attacker has already:
- Confirmed your endpoint exists and is responding
- Identified what software version you’re running
- Determined which CVEs are potentially applicable
- Decided whether you’re worth continued attention
Your WAF is the lock on the front door. It’s good to have, but it doesn’t stop someone from knowing your address, watching which hours you’re home, or testing whether your lock model has a known bypass. The WAF fights on your attacker’s terms, not yours.
A Better Solution: Eliminate API Reachability Until Identities are Verified
NetFoundry takes a structurally different approach. Instead of exposing an API endpoint and then filtering who can use it, the endpoint simply doesn’t exist on the public internet.
There are no open inbound ports. There is nothing for Shodan to index. There is no address to credential-stuff. There is no endpoint to fingerprint.
Here’s how it works.
Without NetFoundry:
Your API server has an inbound port open – port 443 or otherwise. The world can reach it. Your WAF inspects the traffic. You manage allowlists, rate limits, and rules to try to separate legitimate callers from malicious ones.
With NetFoundry:
Your API server has no open inbound ports. It opens an outbound-only connection to a private overlay network. The only parties who can establish a session to your API are those who have a valid cryptographic identity issued by your policy – a certificate bound to a specific workload or partner, not a shared API key that can be copied and reused.
If an attacker runs a Shodan scan, your API doesn’t appear. There is no port to find. There is no endpoint to fingerprint. There is nothing to attack because there is nothing to reach.
Do Public-Facing APIs Need Open Inbound Ports?
This is the right question, and the answer is: it depends on what you mean by publicly accessible.
If you mean “anyone on the internet should be able to call this API without any prior enrollment,” then yes, you need a reachable endpoint. A public search API or a consumer-facing webhook receiver genuinely needs to be reachable to unknown callers.
But most APIs that organizations describe as “public” are actually partner APIs, B2B integration endpoints, internal service mesh connections, or machine-to-machine calls where the callers are known in advance. They’re “public” in the sense that they’re accessible over the internet – not in the sense that the caller list is open-ended.
For every one of those cases, the caller can be enrolled in the NetFoundry overlay with a certificate identity. The API remains invisible to everyone else. The surface area of “things an attacker can reach” drops to zero for that endpoint.
For the genuinely public cases – consumer-facing, open-caller APIs – NetFoundry complements rather than replaces traditional API security controls. You still want a WAF in front of a truly open endpoint, but most APIs described as public don’t actually need to be reachable to unauthenticated actors. They just haven’t been built any other way, because until recently there wasn’t a practical alternative.
Identity-First Reachability Blocks Lateral Movement – WAFs Don’t
There’s a second issue that API gateway models rarely address: once an attacker is through your API, what can they reach?
Traditional network architectures connect APIs to internal services, databases, and other APIs over flat networks or broadly trusted segments. Getting past the API gateway is often sufficient to begin moving laterally, not because the gateway failed, but because the network east-west of the gateway wasn’t segmented to assume the gateway could be compromised.
NetFoundry’s overlay defines access at the service level, not the network level. Each identity, whether it’s a partner calling your B2B API, an internal service, or an AI agent, has access to exactly the services its policy permits and nothing else. There is no network path to anything else. Lateral movement requires a network to move through. An identity-defined overlay doesn’t provide one.
Zero Trust API Security in Practice: Real Enterprise Results
We work with enterprises that have closed inbound ports on APIs serving billions of sessions per year – B2B integrations, third-party connectivity, AI agent traffic. The change from a security operations standpoint is significant:
- Shodan and Censys return nothing for those endpoints
- Pen testers have reported “no reachable attack surface” for those services
- Credential stuffing attempts against those endpoints drop to zero, not because the traffic is filtered, but because there is no address to stuff
- Security reviews for new partner or customer API integrations move faster because the partner is asking to enroll an identity, not asking you to change a firewall rule
The WAF doesn’t go away. For genuinely public endpoints it still earns its place. But for the large majority of enterprise API traffic – machine-to-machine, partner, B2B, AI agent – the question shifts from “how do we filter bad traffic” to “how do we make sure only known identities can generate any traffic at all?”
That’s a fundamentally more defensible position.
See how NetFoundry secures API connectivity https://netfoundry.io/api-security/
