Zero Trust Access: A Practical Guide for Web Applications

What is zero trust?

Zero trust is an approach where a request is not trusted because it "came from the internal network"; each access is verified separately against identity and context. NIST defines it in SP 800-207: network location alone grants no authority, and access is decided per resource.

For web applications the plain reading is this: if your admin panel is reachable from the internet, everyone can see the login form and guess passwords. A zero trust layer puts a gate in front of that form too.

What should not sit on the open internet?

Three kinds of systems get targeted often:

• Admin panels. Paths such as /admin, /wp-admin and /dashboard are the first thing automated scanners look for. A weak password or a software flaw turns an attack straight into admin rights.
• Staging and test environments. They are usually patched less than production, may hold a copy of real data, and can leak into search engines.
• Internal tools. Grafana, Kibana, n8n and database admin UIs ship with their own authentication, but that authentication is often weak.

What they share: the user base is small and known. If nobody needs anonymous access, closing anonymous access is the cheapest defense.

VPN or an identity-aware access layer?

A VPN works at the network level: the connected user is inside the network and can reach everything on it. You also have to install and manage a client for every employee.

An identity-aware access layer works at the application level. As the visitor goes to the application, a reverse proxy steps in, asks for proof of identity and forwards the request only if it checks out. No client install is needed; a browser is enough. The architecture is covered in what is a reverse proxy.

Neither replaces the other. SSH and database ports need a VPN or a firewall rule.

Proving identity: e-mail OTP and TOTP

E-mail OTP sends a one-time code to the user's address. It is easy to set up and needs no extra app. Its weakness is that it depends on mailbox security; codes can be delayed or land in spam.

TOTP is a time-based one-time password (RFC 6238). An authenticator app and the server share a secret, and both derive a code from the current time window, commonly 30 seconds. It builds on HOTP (RFC 4226). It needs no network and does not depend on a mailbox, but if the phone holding the secret is lost you need a recovery plan.

Requiring both means an attacker must take over the mailbox and the phone. For sensitive panels this is the most reasonable choice.

Scope: what, for whom, on which path?

A good access rule answers three questions:

1. Which path? The whole site, or only a prefix such as /admin? A narrow scope leaves public pages alone.
2. Which IPs? Adding your office's fixed address to an allow-list lets traffic from it skip the authentication step. Keep the list tight; if a compromised device connects from that IP, the gate stays open.
3. Which exceptions? Webhooks, payment callbacks, health checks and mobile-app APIs cannot enter an OTP. Put them in the excluded paths.

A session cookie spares the user from authenticating on every request. Keep its lifetime short and be careful in environments with shared devices.

Why session cookies matter

Entering an OTP on every request is not workable. After verification the proxy gives the browser a session cookie and from then on only checks the cookie. That cookie behaves like a password: if it is stolen, the thief gets in as the owner. Three measures help: set the cookie Secure and HttpOnly, keep its lifetime as short as your work allows, and ask users to sign out on shared computers.

Session length is a trade-off. Too short and users must enter an OTP every hour, and people will lobby to remove the gate. Too long and a lost device becomes a bigger risk. A same-day lifetime for sensitive panels and a longer one for low-risk staging is a reasonable start.

Bypass risks

An identity layer assumes traffic really passes through it. If an attacker finds your origin server's IP and connects directly, they never see Zero Trust. That is why the origin must accept traffic only from the proxy; see origin IP hiding and origin lock.

Other risks:

• Over-broad exclusions. An exclusion such as /public/* can be bypassed with /public/../admin if path normalization is wrong. Verify that matching runs on the normalized path.
• Brute force. If the OTP endpoint allows unlimited attempts, codes can be guessed. Attempt and send limits are mandatory.
• Weak recovery. If the "I got the code" flow can be talked around through social engineering, the layer is worthless.

Bot traffic needs a separate layer; see bot protection.

Rollout order

1. Decide what to protect (/admin, the whole staging site).
2. List webhook and API paths and exclude them.
3. Pick the method; require both on a sensitive panel.
4. Add office IPs to the allow-list, only truly fixed ones.
5. Test from another device and network; confirm that a signed-out browser hits the gate on the panel path.
6. Make the origin reachable only from the proxy.

Sources

• NIST SP 800-207: Zero Trust Architecture
• RFC 6238: TOTP
• RFC 4226: HOTP

Related product pages:Technology