Safeguard
Application Security•

CWE-654 Reliance on a Single Factor in a Security Decision

If one stolen or spoofed factor unlocks everything, the whole control fails with it. Layer independent checks at more than one choke point.

Safeguard Security Team
3 min read

CWE-654 describes a protection mechanism that relies exclusively, or largely, on a single condition, object or entity to decide whether to grant access. One password, one token, one IP check, one header. It affects authentication systems, API gateways, internal tools and anything where a single signal means "allow".

How it happens

Single-factor designs are easy to build and easy to explain, so they are everywhere. The trouble is that the factor can be stolen, guessed or faked. When that happens, the system cannot tell the legitimate owner from the attacker.

MITRE's observed example is CVE-2022-35248: a chat application skipped validation when Central Authentication Service (CAS) was enabled, effectively removing the second factor from two-factor authentication. The design had two factors on paper. A code path made it one in practice, and that is the same weakness.

Other familiar shapes: an admin page protected only by a network location, or an API that trusts a single shared key for every caller and every action.

What an attacker gains

MITRE lists two consequences. If the single factor is compromised, the integrity of the whole mechanism can be violated for the user identified by that factor, which lets the attacker gain privileges or assume identity. And non-repudiation suffers: it becomes difficult or impossible to tell legitimate actions by the factor's owner from the attacker's.

How to find it

The record lists no detection methods. Review each sensitive action and ask what single thing, if stolen, would unlock it. Check every branch of the login and authorization code: are there configurations, fallbacks or integrations (like the CAS case above) that skip a check? Test with a valid first factor and a missing or invalid second one.

How to fix it

MITRE's mitigations, both at the design stage:

  1. Use multiple simultaneous checks before granting access to critical operations or privileges. Several successive checks, meaning layers of security, are weaker but still helpful.
  2. Use redundant access rules on different choke points, such as firewalls.

For example, require authentication and an authorization check on the resource, plus a network control in front. Make sure that turning on a feature or integration cannot silently remove a check, and add a test that proves it.

Quick check

Does two-factor authentication guarantee two checks?

Only if the code enforces both on every path. The CVE in the record shows a configuration that skipped the second factor entirely.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.