Defense in Depth: Link Security Layers

When you protect a link with ShareZT, you aren't switching on one feature. You're wrapping the content in a stack of independent layers, each evaluated on our servers, each able to stop a request entirely on its own. A visitor has to clear every layer that applies; defeating one earns them nothing but the next. That is defense in depth, and it's the organizing idea behind everything below.

This piece walks the stack from the outside in — from the moment a request arrives at the edge, through each check it has to satisfy, down to the encrypted payload at the center.

The stack at a glance

A request to a protected link is evaluated in a deliberate order:

Flood control — is this source sending too much, too fast?
Lifecycle — is the link still alive at all?
IP rules — is this address allowed?
Geo-fence — is this location allowed?
Passphrase — does the visitor know the secret word?
The encrypted payload — and even past the gate, can they actually read it?

Underneath all of it sits a foundation that makes the per-visitor checks meaningful in the first place, and around it sits a principle — fail closed — that decides what happens whenever a layer is in doubt. A request that fails any layer stops there. Only a request that clears all of them reaches the content.

The foundation: knowing who's actually knocking

Three of the layers above judge the visitor — their address, their location, how much they're asking for. Those checks are only as honest as the identity they evaluate, and that's where layered infrastructure quietly fails: by the time a request reaches the application, the "client IP" has often been rewritten to some intermediate hop, so an IP, geo, or rate-limit rule ends up judging your own infrastructure instead of the person at the keyboard.

ShareZT carries the genuine client address end-to-end so every per-visitor decision evaluates the actual visitor. And it only accepts that forwarded identity from its own trusted edge — a request that tries to assert its own address from somewhere else doesn't get to. This isn't a layer you "pass" so much as the ground the other layers stand on; without it, they'd be measuring the wrong thing.

Layer 1 — Flood control

The outermost ring throttles volume before any expensive work happens. Traffic to a protected link carries a ceiling, and once a source crosses it, further requests are turned away with a clear retry signal rather than being quietly serviced. This layer is cheap to enforce and exists largely to protect the layers behind it: it ensures no single source can exhaust the gate or grind through the more involved checks by brute volume. In practice, an abusive client mostly succeeds in rate-limiting itself.

Layer 2 — Lifecycle: is the link even alive?

Before ShareZT spends effort on who you are, it asks whether there's anything to reach at all. A link that has been revoked, has passed its expiry, or has hit its view limit is spent, and a spent link never advances to the later checks or the payload. This is the cheapest definitive gate in the stack, which is exactly why it runs early — there's no reason to evaluate an address or a passphrase for a link that no longer grants access to anything. It's also the layer that makes one-time and time-boxed access real: when access is supposed to be over, this is where "over" is enforced.

Layer 3 — Who: IP access rules

Now the stack starts judging the visitor. IP rules come in allow-list and block-list form and are matched against the real address established by the foundation layer. Matching is precise: individual IPv4 and IPv6 addresses, and CIDR ranges, compared as actual network math rather than by string prefix — so 10.0.0.0/8 means the network it describes, not "anything that happens to start with those characters." It's a coarse layer by design, and a fast one, narrowing the field to addresses you've decided are eligible before any heavier lookup runs.

Layer 4 — Where: the geo-fence

On top of which address, you can gate on which country. Geo rules allow or block by location, backed by an industry-standard geolocation database. True to the principle that binds the whole stack, this layer fails closed: if a location can't be established, the request is denied rather than waved through on the benefit of the doubt.

It's worth being candid about what this layer is and isn't. IP geolocation is a best-effort signal — VPNs, proxies, and the inherent imprecision of mapping addresses to places mean it raises the bar rather than forming an impervious wall. That limitation is precisely why it fails closed instead of guessing, and why it's one layer in a stack rather than a wall you'd ever lean the whole weight of a secret against.

Layer 5 — Knowledge: the passphrase

The last gate before the payload asks for something the visitor must know. A per-link passphrase sits on top of where they are and what address they hold, and it's hardened against the obvious attack: repeated wrong guesses on a link trigger a temporary lockout, so the password can't be ground down by automation. Verifying a passphrase is intentionally slow work — that slowness is what resists guessing — and it's handled so that a burst of attempts from one source can't stall the gate for everyone else. Knowledge, location, and network identity are independent factors, and a link can require all three at once.

The core: an encrypted payload, the last layer standing

Here is the layer that makes the rest robust rather than merely sequential. Suppose every outer check were somehow defeated. What sits at the center is still ciphertext.

For text secrets, ShareZT is zero-knowledge by default: the secret is encrypted in your browser with AES-256-GCM, and the key travels only in the link's fragment — the part after the # that browsers never transmit to a server. We store ciphertext and never receive the key. So the innermost layer is one that even we can't peel back. Put plainly, the gate decides who receives the encrypted content, and the key decides who can read it; clearing the gate without the key yields nothing but an unreadable blob, and holding the key without clearing the gate yields nothing to decrypt. (For cases where you'd rather ShareZT be able to serve the secret directly, an optional server-side mode encrypts it with the same algorithm at rest under a key we manage — strong protection against a stolen database, with the honest trade that we can decrypt it.)

AES-256-GCM also makes this layer tamper-evident: its authentication tag means altering the ciphertext by a single byte causes decryption to fail outright rather than return corrupted or attacker-shaped data. The boundary to keep in mind is that, with zero-knowledge, the complete link is the secret — anyone holding the full URL who clears the gate can read it, and a lost link can't be recovered, because there's nothing on our side to recover it with.

Self-destruction: a layer that removes the target

The strongest protection for a secret is for it to stop existing once its job is done, and ShareZT treats destruction as part of the stack rather than an afterthought. When a burn-after-read link is opened and clears the gate, the stored ciphertext is deleted, not merely flagged as spent. The same erasure happens when a secret reaches the end of its life by expiring or exhausting its views, and a background process ensures nothing lingers even if the link is never reopened. Manual revocation is deliberately the exception — because revoke is meant to be reversible, it disables a link without destroying its contents — but every irreversible outcome actually erases. A link that has done its work leaves nothing behind to leak.

Why the order — and the independence — matter

Two properties make this a stack rather than a checklist. The first is ordering: the cheapest, most definitive layers run first, and the costlier ones only run for requests that have already earned them, so the gate spends its effort where it can still make a difference. The second, and the more important, is independence: each layer stands on its own, so one failing doesn't cascade into the next. Binding both together is the rule the whole system defaults to — fail closed. Any layer that can't reach a confident yes returns a no. The practical consequence is graceful degradation: when something goes wrong in this gate, its failure mode is closed, not open.

So a protected ShareZT link is a series of locks, not a single latch. An attacker doesn't face one obstacle to pick; they face every applicable layer in turn, each independent of the last — and the innermost of them is one we couldn't open for them even if we wanted to.

Want to see how these layers compose for a specific scenario — a one-time credential, a region-locked document, an internal-only link? We're happy to walk through it.