The traditional security model draws a perimeter around the network and trusts everything inside it. This made sense when applications ran on on-premises servers accessed by employees on managed devices within the office. That world no longer exists. Applications run in the cloud, users work from anywhere, devices are unmanaged, and the network perimeter has dissolved. Zero trust acknowledges this reality: trust nothing, verify everything, assume breach.
Why Perimeter Security Failed
Perimeter-based security assumes that once a request originates from inside the network, it's trustworthy. This assumption has catastrophic consequences:
- Lateral movement: An attacker who breaches any internal system can move freely across the network because internal services trust internal traffic.
- VPN compromise: VPN credentials grant full network access. A single compromised VPN account provides the same access as being physically present in the office.
- Cloud dissolution: When applications and data live in multiple cloud providers, SaaS platforms, and edge locations, there's no single perimeter to defend.
- Remote work: Users access corporate applications from home networks, coffee shops, and airports. The network they're on is untrusted by definition.
Every major breach of the past decade — SolarWinds, Colonial Pipeline, MOVEit — involved lateral movement after initial access. The perimeter was breached, and then nothing stopped the attacker from reaching high-value targets because everything inside was trusted.
Zero Trust Principles for Web Applications
Applying zero trust to web applications means treating every request as potentially hostile, regardless of its origin:
- Verify explicitly: Every API request must carry authentication credentials that are validated on every call. Session tokens, JWTs, or API keys must be verified independently — not assumed valid because the user authenticated five minutes ago on a different endpoint.
- Least-privilege access: Each user, service, and component gets the minimum permissions needed for its function. A reporting service that reads data shouldn't have write permissions. A user in the marketing department shouldn't have access to engineering dashboards.
- Assume breach: Design systems as if the attacker is already inside. Encrypt data in transit between internal services, not just at the edge. Log every access. Monitor for anomalous patterns. Segment services so that compromising one doesn't cascade to others.
Microsegmentation in Practice
In a zero-trust web architecture, each service communicates only with the specific services it needs, using authenticated and encrypted channels. A payment processing microservice can reach the database and the payment gateway — nothing else. A user-facing API can reach the authentication service and the application database — not the admin panel, not the monitoring stack, not the CI/CD system.
This containment limits the blast radius of any single compromise. If the payment service is breached, the attacker can't pivot to the admin panel because there's no network path and no credentials that provide access.
Identity as the New Perimeter
When the network perimeter dissolves, identity becomes the primary security control. Zero trust web applications authenticate every request based on:
- User identity: Who is making the request? Verified through strong authentication (MFA, WebAuthn).
- Device posture: Is the device managed, patched, and encrypted? Unmanaged devices may get reduced access.
- Request context: Is this request consistent with the user's normal behaviour? A login from a new country triggers additional verification.
- Resource sensitivity: Higher-value resources require stronger authentication signals. Viewing a dashboard requires standard auth; exporting all customer data requires step-up verification.
The Web Application Surface
For web applications specifically, zero trust translates into concrete technical requirements: HTTPS everywhere (including internal service communication), strong authentication on every endpoint, granular authorisation checks, security headers that prevent cross-origin attacks, and comprehensive logging. Each of these is a layer that removes implicit trust from the system.
Security headers are a particularly relevant zero trust control. A Content-Security-Policy removes implicit trust in script sources. HSTS removes implicit trust in the network layer. SameSite cookies remove implicit trust in cross-site requests. Each header replaces a "trust by default" assumption with an explicit policy.
ShieldReport evaluates your domain's external security controls through a zero-trust lens — verifying that your TLS, headers, cookies, and DNS configuration enforce explicit trust rather than assuming it, providing continuous verification of your security posture.