When a Constructor Became a Security Boundary

I was auditing the initialization layer of one of my Rust systems when I noticed something that looked completely harmless.

A constructor accepted an object that wasn't fully valid yet and relied on a later validation step to reject it if something was wrong.

At first, I didn't think much about it. The object would eventually be validated anyway.

Then it hit me.

For a brief moment, an impossible state existed inside the system.

It didn't matter that the state lived for only a few instructions. It didn't matter that validation would eventually reject it.

The invalid state had already been created.

That was the vulnerability.

The audit completely changed how I think about constructors. I no longer see them as functions that merely initialize data.

I now think of them as security boundaries.

---

A Pattern That Looked Correct

The constructor looked innocent enough.

pub fn try_new(header_length: u32, ...) -> Option {
if header_length < Header::SIZE as u32 {
return None;
}

Some(Self {
    header_length,
    // ...
})

}

At first glance, this seems perfectly reasonable.

Reject obviously malformed inputs and let a later validation step enforce the remaining invariants.

For years, this was implicitly my mental model:

Construct
↓
Validate
↓
Use

Nothing looked broken.

The problem is that this design allows an impossible object to exist, even if only temporarily.

And once an invalid state exists, all bets are off.

---

The Real Vulnerability

At this point, I stopped looking at the constructor and started looking at the object's lifetime.

The model was effectively this:

Construct
↓
Impossible state exists
↓
Validate later
↓
Use

The object may only live in an invalid state for a few instructions or a few microseconds.

That sounds harmless.

It isn't.

The problem with transient invalid states is not their duration.

The problem is their existence.

The moment an impossible state exists, every assumption built on top of your invariants becomes questionable.

An invalid object can:

• leak into another subsystem,
• trigger assumptions that later become bugs,
• cause panic propagation,
• violate invariants,
• or create Time-of-Check to Time-of-Use (TOCTOU) style hazards.

None of these failures are guaranteed to happen.

That's what makes them dangerous.

They become architectural landmines waiting for future code to step on them.

I realized I had been treating validation as a repair mechanism.

It shouldn't be.

Validation should be the gate that prevents impossible states from ever entering the system.

---

A Different Mental Model

I no longer think in terms of:

Construct
↓
Validate
↓
Use

I think in terms of:

Validate
↓
Construct
↓
Use

Or even more simply:

Valid object
or
No object.

There should never be an intermediate state.

---

The Doctrine

This audit reinforced a principle that now governs my Rust designs:

Invalid states should not be repaired.

Invalid states should not be rejected later.

Invalid states should never exist.

---

Final Thoughts

I no longer design constructors to initialize data.

I design them to defend invariants.

Because the most dangerous bugs are often not memory corruptions.

They are the impossible states we accidentally allow to exist.