Zero Trust for web apps: IAM, secret rotation, audit logs, and least privilege

Zero Trust is a permission design mindset#

Zero Trust does not mean buying one security product. It means designing systems under the assumption that networks, users, services, and tokens can be misused. Every request should be authenticated, authorized, scoped, and observable enough for investigation.

For smaller web apps, practical Zero Trust starts with secure cookies, real admin authentication, reduced public fields, server-only service keys, rotated secrets, and database policies that enforce least privilege.

Authentication is not authorization#

Authentication answers who the user is. Authorization answers what they can do to which resource. A common API flaw is checking only that a user is logged in, then allowing access to arbitrary object IDs.

if (invoice.ownerId !== session.userId && !session.roles.includes('admin')) {
  return forbidden();
}

Authorization belongs on the server. Hiding buttons in the frontend improves UX, but it is not a security boundary.

Least privilege#

Each credential should have the minimum required permission. Public frontend code uses an anon or publishable key with strict RLS. Server admin code uses service role credentials only on the server. CI/CD can deploy only the intended project. Runtime database users should not have schema-destroying permissions when they only need application reads and writes.

Secret rotation#

Prepare to rotate API keys, admin keys, webhook secrets, and database passwords without downtime. For important keys, use a dual-key rollout: add a new key, deploy the app to use it, verify traffic, then revoke the old key.

If a secret was committed to Git, deleting the commit is not enough. Revoke the secret because history may already be cloned.

Audit logs#

Admin systems should record who approved comments, edited posts, deleted messages, or changed configuration. Log actor, action, resource, timestamp, and relevant request metadata for destructive or user-data-sensitive actions.

Common defenses#

• XSS: sanitize HTML, escape output, use CSP, and avoid unsafe rendering of user content.
• CSRF: use SameSite cookies, Origin/Sec-Fetch-Site checks, and tokens for high-risk forms.
• Brute force: rate limit login, contact, comments, and search.
• IDOR/BOLA: authorize every object access on the server.
• Data leakage: return only required public fields.

Checklist#

• Every write endpoint has auth, authorization, and validation.
• Admin cookies use HttpOnly, Secure in production, and SameSite.
• Secrets have owners, storage locations, rotation dates, and revoke procedures.
• Public responses omit sensitive fields.
• Database RLS or equivalent policies are tested.
• Important admin actions have audit trails.

Primary references#

• OWASP API Security Top 10 2023
• OWASP CSRF Prevention Cheat Sheet
• OWASP XSS Prevention Cheat Sheet