How do developers prevent Shatter?

Where Shatter shows up in code

shatter is a design flaw, not just a single bug pattern. It appears when one security decision is split across separate checks, separate code paths, or separate pieces of mutable state, so the application no longer makes one coherent decision at one point in time. That creates gaps between steps where state can change, a check can be bypassed, or the wrong combination of conditions can be accepted.

In practice, the problem often appears in workflows that look safe on paper but are only safe if every step stays aligned. If authorisation is checked in one place and the sensitive action happens elsewhere, or if related fields are validated independently instead of together, the attacker may be able to mix a permitted fragment with an unsafe fragment and still reach an invalid outcome.

Developers reduce that exposure by treating the decision as a single unit wherever possible. Centralised policy evaluation, server-side enforcement, and atomic state transitions all help because they shrink the window where a partially updated or partially checked object can be abused. The key question is whether the security decision still holds if the attacker can interleave requests, race updates, or influence one step but not the next.

Why split decisions become exploitable

Shatter is dangerous because each fragment may appear reasonable in isolation while the whole sequence is unsafe. A fragmentary check can confirm one condition, but if another condition is assumed later, the attacker only needs to manipulate the order, timing, or shape of the request to produce a result that the developer never intended.

This is closely related to incomplete mediation, time-of-check to time-of-use gaps, and race-condition style failures. The attacker is not necessarily breaking cryptography or guessing credentials. They are exploiting the fact that the system trusted intermediate state, or trusted a later step to preserve the assumptions made by an earlier one.

CWE Top 25 Guide is useful here because Shatter fits the broader class of software weaknesses where validation, state handling, and access decisions must be designed as a coherent control rather than a series of loosely connected checks.

OWASP Cheat Sheet Series gives developers practical patterns for centralising checks, validating inputs consistently, and avoiding security logic that can be fragmented across handlers or layers.

How to prevent it without overengineering

Prevention starts with deciding where the authoritative security decision lives. If one component owns the decision, other components should consume the result rather than recreating the logic in parallel. That reduces drift, makes testing easier, and prevents subtle disagreements between modules that should have behaved identically.

Use atomic updates when the application must change state and enforce a rule at the same time. If an operation cannot be made atomic, then the fallback should be explicit compensating logic, not silent reliance on “the next step will catch it.” Where shared mutable state exists, assume concurrency, retries, and partial failures will happen.

NIST Cybersecurity Framework 2.0 helps frame this as a governance and control problem as much as a coding problem, because the real issue is whether the organisation can consistently identify, protect, and verify the trust boundaries where security decisions are made.

Risk and Threat Considerations

Shatter creates a control gap that attackers can deliberately compose into a bypass. The exposure is highest when the split decision affects authorisation, workflow state, or any condition that can be influenced between checks, because the attacker only needs one weak point in the chain to undermine the whole control.

Failure mechanism: A security decision is fragmented across multiple checks or state transitions, and an attacker exploits the mismatch between those fragments through ordering, timing, or partial-state manipulation.

Impact: Controls can be bypassed, invalid state can be committed, and downstream systems may act on decisions that were never valid as a whole.

Practitioner Guidance

What to verify: Review whether the same security rule is being enforced in more than one place, and confirm that the final sensitive action cannot proceed unless the authoritative decision is still valid at the moment of execution. If the answer depends on a sequence, test the sequence under concurrency and retry conditions, not just the happy path.

Common mistake: Teams often assume that “checked earlier” is equivalent to “safe now.” That assumption fails whenever the protected object, related attributes, or surrounding workflow can change between steps. The safer pattern is to keep the decision and the protected action as close together as the design allows.

Practitioner takeaway: Shatter is prevented less by adding more checks than by making the decision indivisible, so the best design is the one that leaves the attacker no useful gap between validation and enforcement.

Related resources from NHI Mgmt Group

• What should developers do to prevent IDOR in APIs and web apps?
• How should developers prevent SQL injection in login forms and API queries?
• How should security teams prevent vulnerable code when developers rely on AI coding assistants and agentic tools?
• How should developers prevent JavaScript memory leaks in web applications?