Zero Trust
debt(d7/e7/b7/t5)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints confirm automated detection is 'no' and the tool listed (semgrep) can only catch specific patterns like auth bypass on internal IPs or missing auth on internal endpoints — but a systemic absence of zero trust principles (e.g. long-lived credentials, no mutual TLS between services) requires careful architectural review and runtime observation, not just a single tool scan.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix ('verify every request explicitly') sounds simple but the common_mistakes reveal the fix spans multiple layers: adding per-request auth to all service-to-service calls, rotating from long-lived to short-lived credentials, instrumenting internal traffic logging — all of which touch many components across the codebase and infrastructure, making this a cross-cutting remediation effort.
Closest to 'strong gravitational pull' (b7). Zero trust applies to web, api, and cli contexts per applies_to, and is tagged as an architectural principle. Every new service, endpoint, or internal call must be designed with explicit authentication and authorisation in mind. This shapes how every integration is built and maintained, imposing a persistent design constraint on every future developer working in the system.
Closest to 'notable trap' (t5). The misconception field explicitly states that developers commonly believe zero trust means 'no one is ever authenticated' when it actually means 'trust is never assumed based on network location.' Additionally, the most common mistake — trusting internal IPs — is a well-documented gotcha that many developers eventually learn, but still frequently misapply. This is a notable, documented trap rather than a catastrophic or subtle one.
Also Known As
TL;DR
Explanation
Zero Trust is a security model that eliminates the concept of a trusted internal network. Traditional perimeter security assumes anything inside the firewall is safe — Zero Trust assumes breach and verifies every request as if it originates from an untrusted network. In practice: authenticate every user and device, authorise every individual resource access, encrypt all traffic (including internal), log everything, and grant least-privilege access. Particularly important for cloud and hybrid environments where the "inside" is not well-defined.
Common Misconception
Why It Matters
Common Mistakes
- Trusting requests because they come from an internal IP — internal networks are routinely compromised.
- Service-to-service calls without authentication — a compromised internal service gets unrestricted access.
- Long-lived credentials instead of short-lived tokens — compromised credentials have a longer attack window.
- Not logging and monitoring internal traffic — lateral movement after initial compromise goes undetected.
Code Examples
// Trust based on network location:
if (in_array($_SERVER['REMOTE_ADDR'], $internal_ips)) {
// Bypass authentication — 'trusted' internal request
return $this->handleAdminAction($request);
}
// Attacker on internal network (via phishing, supply chain) bypasses all auth// Zero Trust — never trust, always verify
// Even internal services must authenticate
// Service-to-service auth with shared secret:
class InternalApiClient {
public function request(string $endpoint, array $data): array {
$token = hash_hmac('sha256', json_encode($data) . time(), $_ENV['INTERNAL_SECRET']);
return $this->http->post($endpoint, $data, [
'X-Internal-Token' => $token,
'X-Timestamp' => time(),
]);
}
}
// Per-request authorisation even inside the network:
class OrderService {
public function getOrder(int $id, User $caller): Order {
$order = Order::findOrFail($id);
if ($order->user_id !== $caller->id && !$caller->isAdmin()) abort(403);
return $order; // verified even on 'trusted' internal call
}
}