Missing Authentication

Missing Authentication for Critical Function

What it is

CWE-306 exists when an application exposes a sensitive function (administrative action, configuration change, account creation, data export) without requiring authentication. Anyone who discovers the endpoint can invoke it. Distinct from CWE-287 (improper authentication, where the check exists but is broken) and CWE-862 (missing authorization, where auth passes but ownership is unchecked).

Why it matters

Missing authentication on a critical function is one of the most catastrophic vulnerability classes: a single unauthenticated /admin/users endpoint can leak every user record, and an unauthenticated /admin/exec can grant remote code execution. The pattern recurs in debug routes that were not removed before production, internal admin tools assumed to be 'protected by being internal,' and microservices accessed via a service mesh whose mTLS configuration was disabled for one path.

Common patterns

•Admin routes (/admin, /internal, /debug) without authentication middleware.
•Backdoor or test routes added during development and forgotten in production.
•Internal services exposed to the network without mTLS or service-mesh authentication.
•Cloud functions or Lambda endpoints reachable on a public URL without an auth check.
•Health endpoints (/healthz, /metrics) that return internal state, not just liveness.
•Public buckets (S3, GCS) that hold sensitive data with no IAM policy.

Languages affected

JavaScriptTypeScriptPythonRubyJavaGoPHPC#

What Deva detects

Deva analyzes route registrations across Express, Fastify, NestJS, Flask, FastAPI, Django, Spring, Rails, Echo, Gin, Phoenix, and Laravel. The scanner cross-references each route handler against the middleware chain that wraps it. Routes whose path matches sensitive patterns (/admin, /internal, /debug, /-/, /api/internal, /api/admin) and that lack any authentication middleware are reported as high severity. The rule pack is configurable per project so teams can label additional path prefixes as critical.

Example

Vulnerable

app.post('/admin/users/:id/promote', async (req, res) => {
  await db.users.update({ id: req.params.id }, { role: 'admin' })
  res.json({ ok: true })
})

Fixed

function requireAdmin(req, res, next) {
  if (!req.user) return res.status(401).json({ error: 'Unauthenticated' })
  if (req.user.role !== 'admin') return res.status(403).json({ error: 'Forbidden' })
  next()
}

app.post('/admin/users/:id/promote', requireAuth, requireAdmin, async (req, res) => {
  await db.users.update({ id: req.params.id }, { role: 'admin' })
  // Audit log every privilege change.
  await auditLog.write({ actor: req.user.id, action: 'promote', target: req.params.id })
  res.json({ ok: true })
})

Explanation

The vulnerable version has no authentication on the promote endpoint. An attacker who discovers the route (often via documentation, JS bundle inspection, or fuzzing) can grant themselves admin privileges. The fix adds two middlewares: requireAuth confirms a valid session, requireAdmin checks the user's role. The promotion is also audit-logged because privilege changes need traceability under most compliance frameworks. Hardcoded role strings should be replaced with a permission system for production use.

Where this fits in OWASP Top 10

A07

Identification and Authentication Failures

Weak, missing, or improperly implemented authentication.

Compliance framework mapping

Framework	Controls
OWASP Top 10 (2021)	A01:2021 Broken Access ControlA07:2021 Identification and Authentication Failures
NIST 800-53 Rev 5	IA-2 Identification and AuthenticationAC-3 Access Enforcement
PCI-DSS v4.0	7.2 Access control system8.3 Strong authentication
HIPAA Security Rule	164.312(a)(1) Access Control164.312(d) Person or Entity Authentication
CMMC 2.0 L2	IA.L2-3.5.1 Identify usersAC.L2-3.1.1 Access control policy